Re: [Lynx-dev] TLS-"transport layer security" & LYNX

[Thorsten Glaser]

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