[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Lynx-dev] TLS-"transport layer security" & LYNX
From: |
Thorsten Glaser |
Subject: |
Re: [Lynx-dev] TLS-"transport layer security" & LYNX |
Date: |
Sat, 28 Jul 2018 18:39:16 +0000 (UTC) |
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
- Re: [Lynx-dev] TLS-"transport layer security" & LYNX, (continued)
- Re: [Lynx-dev] TLS-"transport layer security" & LYNX, Mouse, 2018/07/23
- Re: [Lynx-dev] TLS-"transport layer security" & LYNX, Thorsten Glaser, 2018/07/23
- Re: [Lynx-dev] TLS-"transport layer security" & LYNX, Mouse, 2018/07/23
- Re: [Lynx-dev] TLS-"transport layer security" & LYNX, David Woolley, 2018/07/24
- Re: [Lynx-dev] TLS-"transport layer security" & LYNX, Stefan Caunter, 2018/07/24
- Re: [Lynx-dev] TLS-"transport layer security" & LYNX, Mouse, 2018/07/24
- Re: [Lynx-dev] TLS-"transport layer security" & LYNX, Halaasz Saandor, 2018/07/29
- Re: [Lynx-dev] TLS-"transport layer security" & LYNX, Larry Hynes, 2018/07/24
Re: [Lynx-dev] TLS-"transport layer security" & LYNX, David Niklas, 2018/07/28
- Re: [Lynx-dev] TLS-"transport layer security" & LYNX, Mouse, 2018/07/28
- Re: [Lynx-dev] TLS-"transport layer security" & LYNX,
Thorsten Glaser <=
- Re: [Lynx-dev] TLS-"transport layer security" & LYNX, Mouse, 2018/07/28
- Re: [Lynx-dev] TLS-"transport layer security" & LYNX, Steffen Nurpmeso, 2018/07/28
- Re: [Lynx-dev] TLS-"transport layer security" & LYNX, Travis Siegel, 2018/07/28
- Re: [Lynx-dev] TLS-"transport layer security" & LYNX, David Woolley, 2018/07/28
- Re: [Lynx-dev] TLS-"transport layer security" & LYNX, Thorsten Glaser, 2018/07/28
Re: [Lynx-dev] TLS-"transport layer security" & LYNX, David Niklas, 2018/07/29