Am Montag, 19. Oktober 2020, 15:03:34 CEST schrieb Hans-Peter Jansen:
Am Montag, 19. Oktober 2020, 12:27:31 CEST schrieb Sebastian Parschauer:
On 19.10.20 12:01, Marcus Meissner wrote:
IMHO an SSL stability initiative is required - even independent of vendors. If anybody else noticed slow browser tabs, slow https file downloads, slow email downloads, or plain hanging, then I'd be glad to team up to join forces against SSL network state machine violations.
I cannot confirm such behavior in general, but I don't have any Leaps with GUIs left.. My Leap 15.2 servers perform a lot of SSL connections in all kinds of different scenarios without troubles.
To be very frank, what you are describing sounds like your employeer or Internet provider deploys a SSL man-in-the-middle proxy which is not fully standards compliant and causes troubles.
Is this assumption correct?
No, it isn't. Then SUSE would do that as well as issues started when I still worked at SUSE. Working from home in Berlin, just regular Vodafone cable modem connection. Tools doing proper SSL handling like e.g. wget work fine.
Now, this is interesting.
I've seen tcpdumps, that have shown "likely" behavior of transparent HTTP/SSL proxies for this very provider as well. Since this is the only way for a decent connection to the world here, I've resisted to hang this on the big bell (and the related "careful" support request remained unanswered..). Hmm. I don't trust anything behind my router cascade anyway.
I have some connections to AK Vorrat, should we sort of get ready to get them involved, and maybe the local privacy officer (or whatever "Datenschutzbeauftragter" is in english)? Or just right away Patrick Breyer? Cheers Mathias and yes i'm actually serious about this. If we can prove that Vodafone is running a man in the middle against SSL.... -- Mathias Homann Mathias.Homann@openSUSE.org OBS: lemmy04 Jabber (XMPP): lemmy@tuxonline.tech IRC: [Lemmy] on freenode and ircnet (bouncer active) telegram: https://telegram.me/lemmy98 keybase: https://keybase.io/lemmy gpg key fingerprint: 8029 2240 F4DD 7776 E7D2 C042 6B8E 029E 13F2 C102