David Niklas dixit: >All that being said, I'd be interested in knowing what Thorsten Glaser >was talking about with respect to TLS 1.3. I though, perhaps somewhat >naively, that all headers, cookies, and the resource(s) you are
That used to be true. Then, people who wanted to host multiple sites on one physical server started to listen to Apache webserver warnings that “having multiple vhosts on one SSL port does not work” (when it works very well, if you have a wildcard or multi-sAN cert) and decided to create an extension to SSL/TLS, called SNI (server name indication), which made its way into OpenSSL 0.9.8 and up. SNI basically transmits the actual vhost you wish to visit, in URL terms the part between https:// and the first slash after that, in plaintext to the server BEFORE SSL is established so the server can choose the “correct” certificate for that domain. This is all to silence webserver and webbrowser warnings, when a number of different ways would have worked too: • for site1.example.com and site2.example.com, use a wildcard certificate for *.example.com instead • for site1.example.com and site2.example.org, use a multi-sAN certificate instead which has subjectAltName contain both DNS:site1.example.com and DNS:site2.example.org attributes • or just use IPv6 and have site1 use IP address 2001:db8::1 and site2 use 2001:db8::2, so you don’t even need vhosts at all This extension was optional for a long time, but more and more sites have started implementing it, including, unfortunately, community-driven projects such as Debian, citing it being a “standard”. (It’s probably been in some RFC.) After some time, we arrived at TLSv1.2 (OpenSSL 1.x) being in widespread use, more cryptographic problems showing up and being solved (incidentally most of them only applying to stuff wildly added to OpenSSL 0.9.8 while those of us who stuck with 0.9.7 were unaffected by most of them and could backport the remaining fixes manually). Then, the people at some green table committee thought it would be good to create TLSv1.3 (which uses completely different ciphersuites too and perhals would better have been TLSv2.0) and decided to add SNI to that standard; not only that, but they *require* it to be used now. Instead of improving security, TLSv1.3 actually reduces privacy. It’s not the first time a standard is idiotic (one of the mandates of POSIX is actually illegal in Germany, for example); choosing to not support SNI will however have a changed outlook now: before, you could tell people to get proper wildcard/multi-sAN certificates or IPv6 instead; now they can reject that suggestion citing SNI is required by TLS, and just ignore one’s problem reports. I doubt this is the only problem with TLS, and newer TLS versions in general. (There's also quite a bit of protocol ossification: embedded systems like ADSL modems, routers, etc. that can’t upgrade will now be unable to connect to those sites requiring newer TLS versions and have to fall back to unencrypted (if at all supported) instead of using the older TLS version that still provides sufficient security unless you are a bank, if you disable a few problematic features and ciphersuites and implement a few countermeasures. Nobody cares, mostly because a conglomerate of Google and Mozilla want to force their latest adver‐ tisement-displaying-engines (aka “modern browsers”) upon you and an easy way to do that is to make the old ones stop working. Disillusioned greetings, //mirabilos -- “It is inappropriate to require that a time represented as seconds since the Epoch precisely represent the number of seconds between the referenced time and the Epoch.” -- IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2 _______________________________________________ Lynx-dev mailing list Lynx-dev@nongnu.org https://lists.nongnu.org/mailman/listinfo/lynx-dev