Subject: [TLS] Broken browser behaviour with SCADA TLS

From: Peter Gutmann <[email-masked]>
Date: Wed, 4 Jul 2018 06:52:33 +0000

The following is an attempt to condense some off-list discussions with SCADA
folks about the broken behaviour of some browsers when it comes to interaction
with SCADA devices running TLS.  tl;dr: Chrome is practically unusable, at the
other end of the scale Firefox is fine, and there's something weird happening
with IE, possibly due to the use of non-CA-bought certificates.

A disclaimer for the following: This involved a lot of fiddling with server
configs to exercise all the different options and recreate what people were
reporting, so there may be some anomalies arising from getting a particular
combination of browser+server config wrong.  I can post a full trace of cipher
suites offered and accepted if anyone's interested.

Browser versions

IE = 11.0.9600.18538
Chrome = 67.0.3396.87
Firefox = last version before they broke all the extensions

DHE + RSA, ECDHE + ECDSA, ECDHE + RSA, RSA only:
Chrome:
[Connects correctly]
Firefox:
[Connects correctly]
IE:
[Does some weird fallback dance where it reconnects using TLS 1.0 several
 times when the cert is unrecognised and you click OK to accept it, then
 closes the connection after negotiating DHE at the point where the server has
 sent its Server Hello Done]

DHE + RSA, ECDHE + ECDSA, RSA only (using RSA server key, so in effect no ECDSA):
Chrome:
[Client negotiates non-PFS pure-RSA and ignores PFS DHE, then disconnects
 after sending/receiving Finished, then reconnects and repeats]
Firefox:
[Connects correctly]
IE:
[Does some weird fallback dance where it reconnects using TLS 1.0 several
 times when the cert is unrecognised and you click OK to accept it, then
 closes the connection after negotiating DHE at the point where the server has
 sent its Server Hello Done]

DHE + RSA, RSA only:

Chrome:
[Client negotiates non-PFS pure-RSA and ignores PFS DHE]
Firefox:
[Connects correctly]
IE:
[Does some weird fallback dance where it reconnects using TLS 1.0 several
 times when the cert is unrecognised and you click OK to accept it, then
 closes the connection after negotiating DHE at the point where the server has
 sent its Server Hello Done]

DHE + RSA only:

Chrome:
[Unable to connect, "The client and server don't support a common SSL protocol
 version or cipher suite"]
Firefox:
[Connects correctly]
IE:
[Does some weird fallback dance where it reconnects using TLS 1.0 several
 times when the cert is unrecognised and you click OK to accept it, then
 closes the connection after negotiating DHE at the point where the server has
 sent its Server Hello Done]

Summary:

Most broken browser unless exactly the right cipher suite is available: Chrome
Least broken browser: Firefox (at least for the last proper version they released)

Peter.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 4 Jul 2018 17:05:08 +1000

On Wed, Jul 4, 2018 at 4:53 PM Peter Gutmann <[email-masked]> wrote:
> ... Client negotiates non-PFS pure-RSA and ignores PFS DHE ...

How is the client doing any of this?  The server picks the cipher suite.

> Least broken browser: Firefox (at least for the last proper version they released)

Newer versions might not have DHE, which I hope is consistent with
your expectations.  But we haven't started on those plans.  As of the
latest version, things should be the same - extensions shouldn't
affect whether connections work.

The problem with DHE of course being that it uses the TLS 1.0 suites
with the SHA1 MAC and with the MAC and encrypt in the wrong order.
And that it is subject to small subgroup attacks from the server
unless it negotiates the FFDHE extension.

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 4 Jul 2018 10:41:01 +0300

> unless it negotiates the FFDHE extension.

More serious problem is servers returning too small modulus due lack
of negotiation. Which was the reason why Chrome disabled DHE.

Also, there are finite-field AEAD ciphersuites in TLS 1.2, which do
not use the broken blockmode nor SHA-1 (but Firefox does not appear to
support any of these):

- AES, ARIA or CAMELLIA in GCM mode, with 128 or 256 bit keys, and with
  RSA or DSS certificate (good luck getting DSS certificate, and even
  more luck getting clients to accept it).
- AES in CCM mode, with 128 or 256 bit keys and 64 or 128 bit tags. Only
  RSA certificates are supported.
- CHACHA20-POLY1305-AEAD with 256 bit keys. Only RSA certificates are
  supported.

-Ilari

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 4 Jul 2018 07:45:36 +0000

>How is the client doing any of this?  The server picks the cipher suite.

Sorry, I meant the client only offers pure-RSA, not DHE+RSA, so the server is
forced to pick pure-RSA, e.g.:

Chrome:

Offered suite: TLS_RSA_WITH_AES_128_CBC_SHA.
Accepted suite: TLS_RSA_WITH_AES_128_CBC_SHA.
Offered suite: TLS_RSA_WITH_AES_256_CBC_SHA.
Offered suite: SSL_RSA_WITH_3DES_EDE_CBC_SHA.

This is on a system without ECDHE present, so the server is looking for DHE
(preferentially) or RSA (if it really has to), the ECDHE suites are skipped.
This was noticed on systems which had disabled the pure-RSA suites because
some industry compliance thing required it, and found that Chrome was now
unusable for any of their devices.

(My suggestion that they might consider QQ Browser didn't go down too
well...).

>Newer versions might not have DHE, which I hope is consistent with your
>expectations

Well, that'd bring FF closer to Chrome's brokenness.  I guess I could add a
comment about FF copying everything Chrome does as being consistent with my
expectations :-).

>As of the latest version, things should be the same - extensions shouldn't

Sure, the only reason for mentioning the "last version with extensions" is
that apparently some of the systems require browser extensions, and they
aren't going to be rewritten for current versions of Firefox.  So it was
whatever the last version with extensions was, either 52ESR or 56 (I didn't
ask, I'm on FF 56).

>The problem with DHE of course being that it uses the TLS 1.0 suites with the
>SHA1 MAC and with the MAC and encrypt in the wrong order. 

Given that SHA-1 is used in the HMAC form it doesn't really matter security-
wise... the order of MAC and encrypt also depends on EtM/LTS support, I didn't
check for who does what there, the real issue was to report on browser issues
when used in a SCADA environment and to poke vendors with a bit of a WTF?! for
their cipher suite support, or lack thereof.  Currently the best by a long
shot is FF.

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Wed, 4 Jul 2018 07:57:41 +0000

Ilari Liusvaara <[email-masked]> writes:

>More serious problem is servers returning too small modulus due lack of
>negotiation. Which was the reason why Chrome disabled DHE.

Why not reject the handshake if the modulus is too small, rather than
disabling all DHE suites on the off chance that the server returns a value you
don't like?

>- CHACHA20-POLY1305-AEAD with 256 bit keys. Only RSA certificates are

Wouldn't matter much anyway, suport for those is practically nonexistent (CCM,
Aria, Camellia, ChaCha20, and so on, I mean).

OK, "practically nonexistent" may be too optimistic, I've never heard of
anything supporting those.  Having said that I don't know of every SCADA
device in existence, maybe some Korean devices somewhere do Aria.

DSA certs aren't a problem since they're all from non-commercial CAs (in-house
or self-signed), but I only know of a few systems using DSA.  Can't remember
why they did that... oh yes, because keygen was faster/more efficient for DSA,
just a single modexp and no requirement for lots of CPU and memory.

Peter.

---

From: Ilari Liusvaara <[email-masked]>
Date: Wed, 4 Jul 2018 11:15:19 +0300

> disabling all DHE suites on the off chance that the server returns a value you

Chrome initially did that. It caused quite a lot of bad feedback from
owners of various bad embedded stuff. The thread on relevant forums was
quite something. Hundreds of messages blaming Google for breaking
stuff.

-Ilari

---

From: Nikos Mavrogiannopoulos <[email-masked]>
Date: Wed, 04 Jul 2018 10:41:31 +0200

> quite something. Hundreds of messages blaming Google for breaking

We had similar experience when we required a minimum of 2048-bit
modulus for all TLS connections in Fedora 28 beta irrespective of back-
end lib. It broke connections to VPN servers and web internal web sites
and we had to revert the change. The DHE ciphersuites under TLS1.2 seem
doomed and rfc7919 couldn't save them.

regards,
Nikos

---

From: Martin Thomson <[email-masked]>
Date: Wed, 4 Jul 2018 19:22:33 +1000

> doomed and rfc7919 couldn't save them.

It has been suggested that 7919 makes things worse.

We have minimum modulus size constraints and haven't had any reports of
issues, but the limits are fairly low and we have a less diverse usage
environment than Redhat.

We're also unable to catch big values that aren't prime, or values with
small subgroups. We end up trusting servers more than we might consider ok
for a modern protocol. That isn't a massive problem in my view.

Of course, our recommendations don't change. Right now, that is to use TLS
1.3, or at least the configuration of TLS 1.2 that most closely resembles
1.3. The rest is stuff we merely tolerate for the sake of interoperability.
Soon, I hope, we might be able to get rid of TLS 1.0 and 1.1, and these
questions will be somewhat less interesting.

---

From: Hubert Kario <[email-masked]>
Date: Wed, 04 Jul 2018 12:01:18 +0200

> whatever the last version with extensions was, either 52ESR or 56 (I didn't

what "browser extensions"? you can't really do a modern TLS 1.2 without 
extensions, let alone TLS 1.3 (which is now enabled by default in NSS). I'm 
quite sure NSS didn't drop any consequential ones...

-- 
Regards,
Hubert Kario
Senior Quality Engineer, QE BaseOS Security team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00  Brno, Czech Republic

---

From: Kurt Roeckx <[email-masked]>
Date: Wed, 4 Jul 2018 14:24:07 +0200

> quite sure NSS didn't drop any consequential ones...

The extensions are not related to TLS, but are extentions /
add-ons of the browser itself. Firefox dropped support for the
old way of doing extensions in version 57. They also added the
WebExtensions API that is also implemented in other browsers.
This required major rewrites of the extensions, and some were
never changed to work with the new API.

Kurt

---

From: David Benjamin <[email-masked]>
Date: Wed, 4 Jul 2018 11:15:45 -0400

> doomed and rfc7919 couldn't save them.

Indeed. The bad feedback was not even at a 2048-bit minimum, but a mere
1024-bit minimum. (Chrome enabled far more DHE ciphers than others, so we
encountered a lot of this.) 2048-bit was completely hopeless. At the time
of removal, 95% of DHE negotiations made by Chrome used a 1024-bit minimum.
See here for details:
https://groups.google.com/a/chromium.org/d/msg/blink-dev/ShRaCsYx4lk/46rD81AsBwAJ

I should add to that link that the "draft specification which fixes the
negotiation problems", now rfc7919, did not fix the problem. This was
pointed out here, but never incorporated to the document:
https://www.ietf.org/mail-archive/web/tls/current/msg18697.html

To the original email, it seems the second and third scenarios are
identical. Configuring ECDHE+ECDSA ciphers is a no-op if using an RSA
server key. The third and fourth scenarios are indeed unsurprising for a
browser that doesn't support DHE. You should instruct these folks to
configure ECDHE+RSA ciphers if they have RSA keys. Particularly in the
second scenario, it seems they're already implemented, just the server was
incorrectly configured to use the wrong ones.

DHE at acceptable sizes is quite slow anyway, so their servers may well
appreciate the speed boost. (Indeed, I often see DHE disabled in server
deployments as otherwise the poor servers would melt.)

---

From: Colm MacCárthaigh <[email-masked]>
Date: Wed, 4 Jul 2018 08:40:26 -0700

>From the server side: we found that enforcing a 2048-bit size was
unworkable, it breaks clients that will negotiate DHE but then fail when
the exchange happens, including versions of Java. Because the breakage
happens post-handshake, there was little recourse to fix it. We did look at
fingerprinting the clients and trying to use a different size for those,
but even that led to too high an error rate. So we removed DHE in general
and use ECDHE for FS.

-- 
Colm

---

From: David Benjamin <[email-masked]>
Date: Wed, 4 Jul 2018 11:54:31 -0400

> of removal, 95% of DHE negotiations made by Chrome used a 1024-bit minimum.

Oops, that sentence should have read:

"At the time of removal, 95% of DHE negotiations made by Chrome used a
1024-bit *group*."

That is, were we to have enforced a 2048-bit minimum, 95% of DHE
connections would have broken. With 5% of it salvageable, the TLS DHE code
points are not worth saving.

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 5 Jul 2018 02:02:04 +0000

Ilari Liusvaara <[email-masked]> writes:

>Chrome initially did that. It caused quite a lot of bad feedback from owners
>of various bad embedded stuff. The thread on relevant forums was quite
>something. Hundreds of messages blaming Google for breaking stuff.

If there were "hundreds of messages" doesn't that indicate that it's Chrome
that's the problem, and not everyone else?

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 5 Jul 2018 02:05:48 +0000

Kurt Roeckx <[email-masked]> writes:

>The extensions are not related to TLS, but are extentions / add-ons of the
>browser itself. Firefox dropped support for the old way of doing extensions
>in version 57. They also added the WebExtensions API that is also implemented
>in other browsers. This required major rewrites of the extensions, and some
>were never changed to work with the new API.

As I understand it (E&OE), the flow was that a bunch of SCADA stuff used
browser extensions, presumably to talk things like IEC 61850.  When the
existing extensions broke, there was a general exodus from Firefox to Chrome,
however when Chrome broke at the TLS level there was indecision about what to
do.  There are also IE plugins, I assume the advice going forwards will be to
use IE.

(I have no idea about the prevalence of IE vs. others, but since it's the
default browser for Windows I assume this will be the easiest/recommended path
fowards, and until Windows 10 MS had a long history of being excruciatingly
careful about backwards compatibility so it seems the safest bet).

Peter.

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 5 Jul 2018 02:32:08 +0000

David Benjamin <[email-masked]>​ writes:

>The bad feedback was not even at a 2048-bit minimum, but a mere 1024-bit
>minimum. (Chrome enabled far more DHE ciphers than others, so we encountered
>a lot of this.) 2048-bit was completely hopeless. At the time of removal, 95%
>of DHE negotiations made by Chrome used a 1024-bit minimum.

How does Google, rather than the people running the systems being connected
to, know that 1024-bit DH isn't secure enough for a given environment?  The
majority of this stuff is running on isolated, private networks or inside VPN
tunnels for which pretty much anything, including 512-bit keys, are fine.

It's also somewhat disturbing that Chrome now walks straight past a perfectly
good PFS DHE suite and instead goes to a problematic pure-RSA one instead.

>You should instruct these folks to configure ECDHE+RSA ciphers if they have
>RSA keys. 

The devices don't do ECDHE, and they probably never will (at least until the
next upgrade cycle, which could take a decade or more), so there's nothing to
configure.

>rfc7919, did not fix the problem. This was pointed out here, but never
>incorporated to the document:

Yep.  The issues were pointed out by several people before it was published,
but got published anyway... with the result being that a number of
implementations chose not to support it because of the problems that it
causes.

>Particularly in the second scenario, it seems they're already implemented,
>just the server was incorrectly configured to use the wrong ones.

That was in my testing, not using a PLC control centre or similar, in other
words the actual devices being used in the field.  Doing that would have
required a firmware reload for each test, which is way too painful to think
about.  For "server incorrectly configured", see above, they were offering all
the suites the firmware and hardware supported.

Peter.

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 5 Jul 2018 09:44:55 +0300

> that's the problem, and not everyone else?

Basically with DHE in TLS 1.2, you have very few choices:

1) Advertise DHE, accept weak groups. Vulernable to LOGJAM.
2) Advertise DHE, deny weak groups. Unacceptable failure rates.
3) Do not advertise DHE. Loses FPS with some servers.
4) Try DHE at first and fallback to RSA on too small group.
   Complex.

-Ilari

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 5 Jul 2018 12:05:01 +0000

>1) Advertise DHE, accept weak groups. Vulernable to LOGJAM.

Only if the weak groups you accept are 512 bits.

A bigger question is, why does Chrome think it's up to it to decide whether
the device user's choice of key size is appropriate or not?  As I mentioned
earlier, in many cases 1024-bit keys are not only perfectly fine but more than
enough.  In fact given the hardness of the DLP they're probably OK in
virtually all cases as long as everyone doesn't share the same group2 prime.

The crazy thing is that although Chrome rejects a connection to a PFS,
relatively safe (via the DLP's hardness) 1024-bit DHE server, it's perfectly
happy connecting to a far less safe (both in terms of factorability and use of
pure RSA) 1024-bit RSA server.  

This is "security" done backwards!

Peter.

---

From: Adam Langley <[email-masked]>
Date: Thu, 5 Jul 2018 06:49:37 -0700

> pure RSA) 1024-bit RSA server.

A 2048-bit minimum for RSA acts via the CA/Browser Forum rules: it
should not be possible to get a publicly-trusted certificate with a <
2048-bit key and, if it happens, we have proportionate measures to
address it.

However, it's not practically possible to fix the small DHE defaults
across all servers and, even if we could, that would have broken many
Java clients. Thus the DHE ecosystem was poisoned and, given that DHE
has been exceeded by ECDHE, it wasn't worth trying to save it.

We have not (at least so far) acted to enforce a 2048-bit RSA minimum
in the client as the CA/BF rules suffice for the vast, vast majority
of users.

Cheers

AGL

-- 
Adam Langley [email-masked] https://www.imperialviolet.org

---

From: [email-masked] (Martin Rex)
Date: Thu, 5 Jul 2018 20:18:27 +0200 (CEST)

Peter Gutmann <[email-masked]> wrote:
> David Benjamin <[email-masked]>? writes:
> 

Silently removing stuff (support for TLS_DHE) is just as bad as silently
adding stuff (automatic, silent and unlimited-times protocol downgrade
dance in the broswer which became famously known as POODLE).

> good PFS DHE suite and instead goes to a problematic pure-RSA one instead.

Cough, what?  TLS_DHE_ was known to be a security disaster beyond fixing
a good decade ago (14-May-2007):

   https://www.ietf.org/mail-archive/web/tls/current/msg01647.html

but it needed a LOGJAM demonstration to have folks look at the
crappy implementations in the installed base.

We didn't have support for TLS_DHE in our SSL implementation back then,
and I decided I never want to have it added.  We've added support for
TLS_ECDHE a few years ago, but TLS_DHE remains unsupported.  Probably
most usage scenarios that still offer TLS_DHE today, provide less security
than with static-RSA 2048-bit.

How often does your SCADA devices (=servers) regenerate its DHE params?
If it is using DHparams for several weeks, months or even forever, then
there is essentially no PFS, and static RSA will be equal or better than DHE.
Static RSA-2048 will always be better than DHE-1024.  Simply regenerate
and roll your RSA keys&server cert if it makes you feel good.

btw. which kind of "problematic pure-RSA" are you talking of?
I'm not actually aware of any problem, and I'm much more concerned
about TLS servers with longterm DHE params or longterm ECDHE keys
and equally about servers using session tickets with a longterm session ticket
encryption key, because of the illusion of PFS, which they create but
do not offer.

-Martin

---

From: [email-masked] (Martin Rex)
Date: Thu, 5 Jul 2018 20:51:33 +0200 (CEST)

> with the SHA1 MAC and with the MAC and encrypt in the wrong order.

I'm confused about what you are thinking here.

In TLSv1.0 through TLSv1.2 inclusive, all of the TLS handshake messages,
including the *KeyExchange handshake messages (with the exception of Finished)
are in the clear and neither MACed nor encrypted, so the ordering
MtE vs. EtM for the GenericBlockCipher record PDU seems quite irrelevant.

-Martin

---

From: Martin Thomson <[email-masked]>
Date: Fri, 6 Jul 2018 09:51:54 +1000

> I'm confused about what you are thinking here.

Just that we don't implement MtE because it was hard and AEAD is
better, that's all.

---

From: Peter Gutmann <[email-masked]>
Date: Fri, 6 Jul 2018 06:33:36 +0000

Martin Rex <[email-masked]> writes:

>Cough, what?  TLS_DHE_ was known to be a security disaster beyond fixing a
>good decade ago (14-May-2007):
>

That's not DHE that's the problem, it's the use of ridiculously short toy keys
that were known to be insecure 20-25 years ago when they were mandated for
export grade use.

>but it needed a LOGJAM demonstration to have folks look at the crappy
>implementations in the installed base.

Sure, LOGJAM pointed it out, and spurred fixes (finally), just like FREAK did
for RSA (and BEAST did, and POODLE did, and CRIME did, and BREACH did, and
FLUFFYBUNNY did, and Heartbleed did, it always takes some attack with a cool
name before people fix their code).  I'm still waiting for a paper to point
out that 512-bit DSA and secp160 are insecure, I assume the lack of public use
of these is what's prevented that.

The point is it has nothing to do with DHE, you've got exactly the same
vulnerability with RSA-512, DH-512, DSA-512, Elgamal-512, and Mr-Not-
Appearing-in-this-List-512.  

LOGJAM had two great contributions, firstly pointing out that there were a
scary number of servers that still allowed toy keys, and secondly providing a
baseline where, if you're worth less than several hundred million to several
billion dollars to an attacker, DH-1024 is still OK (as long as it's not
group2, that one's a bit too risky).

>Probably most usage scenarios that still offer TLS_DHE today, provide less
>security than with static-RSA 2048-bit.

Sure, if you choose your DH key to be 512 bits and your RSA key to be 2048,
you can make that claim.  I'm going to choose my RSA key to be 128 bits and my
DH key to be 16384 bits, in which case DH wins again.  And by quite a margin,
I must say.

>How often does your SCADA devices (=servers) regenerate its DHE params?

That's a question I can't answer in general because I've only seen the source
code for a small number of vendor-specific embedded implementations (under
various NDAs), but both from the code and from knowing the coding style used
for these implementations, they'll do so on every connection because that's
how the textbooks describe it.  

These implementations do just enough to connect to a client or server (some
act as clients connecting to things like PLC control centres).  They are the
bare minimum needed to function.  Cert processing is done with memcpy() of a
pre-encoded blob.  TLS extensions are encoded with memcpy() and decoded with
memcmp().  You get the picture.  No-one would even think of the possibility of
cacheing DH parameters, let alone sit down and write the code for it.

>Static RSA-2048 will always be better than DHE-1024.  

Since this will be exposing a private-key op with every decryption oracle and
side channel known to research science directly to anything on the network
(see the comment above on how these implementations are written), I'm going to
disagree with you there.  With DH you've admittedly still got the RSA sig, but
that's buried behind/under so much other stuff I doubt it's exploitable.

>Simply regenerate and roll your RSA keys&server cert if it makes you feel
>good.

Since that could involve a firmware reflash (with the new cert coded into the
firmware), on a remote device that can never go offline, it's not likely to
happen.

In a previous message I mentioned an example of using DSA for TLS.  This is
because you can generate a DSA key in essentially zero memory with a single
modexp, which completes before the watchdog times out and restarts the system.
You can't do that with RSA in hard real-time.  

Also, there's no way to "roll the cert", it's baked in at the factory or when
the device is deployed.  Well, a reflash I guess, but then see above.

>btw. which kind of "problematic pure-RSA" are you talking of?

See above, exposing your private key via every kind of side channel and
decryption oracle to a network attacker.

>because of the illusion of PFS, which they create but do not offer.

Maybe I shouldn't have mentioned PFS, I used that as an example because it was
quicker than writing several paragraphs on why pure RSA is dangerous.  PFS is
actually more or less irrelevant for SCADA, it's something cryptographers care
about but SCADA folks don't because pretty much all the traffic being carried
is tactical, no-one's worried about an attacker being able to go back later
and see that you sent a pilot-operated relief valve activation command two
weeks ago in your non-PFS encrypted traffic.

Peter.

---

From: [email-masked] (Martin Rex)
Date: Sat, 7 Jul 2018 02:30:21 +0200 (CEST)

> careful about backwards compatibility so it seems the safest bet).

The last time that I've seen a Microsoft Windows TLS implementation
show a reasonble level of interoperability was Windows2003sp2
with Hotfix 948963 installed.

Windows 2008R2 has sever interop problems with TLSv1.2,
and goofed the RSA premaster secret version check.
   https://www.ietf.org/mail-archive/web/tls/current/msg08139.html

Windows2012R2 made things worse, same TLSv1.2 interop failures,
plus default lack of backwards compatibility to non-SNI clients.

I was surprised when I just recently saw responses from Windows 2016
   Microsoft IIS/10.0 = presumably Windows 2016
   Microsoft IIS/8.5  = Windows 2012R2
   Microsoft IIS/7.5  = Windows 2008R2

While 2016 seems to have fixed two annoying TLSv1.2 interop failures that
affect 2008R2 and 2012R2 (about the TLSv1.2 signature_algorithms extension),
Win2016 also newly added two _new_ handshake failures (compared to 2008R2)

Comparing Win2016 behaviour for SSLv2Hello vs. extension-less SSLv3 Hello
the new behaviour is just crazy: the server requires TLS extension SNI
for SSLv3 ClientHellos with client_version=(3,1) and (3,2),
but *NOT* for client_version=(3,3) and *NOT* for SSLv2Hellos (any version)!

I would expect that someone who cares about backwards compatibility
would test stuff at least once before shipping.

Windows 2008R2 and later looks like entirely untested to me
or maybe "tested only with MSIE and only in default config"
-- which is equivalent to "untested" on my scorecard.
Windows 2008R2 in default config had TLSv1.2 disabled,
and no one seem to have thought of testing with a sha256WithRsaEncryption
signed server certificate.

-Martin

All cells marked with ** are SChannel Bugs.

                               2003     2008R2    2012R2     2016
--------------------------------------------------------------------
SSLv2Hello offering (3,1)     TLSv1.0   TLSv1.0   **FAIL    TLSv1.0

SSLv2Hello offering (3,2)     TLSv1.0   TLSV1.1   **FAIL    TLSv1.1

SSLv2Hello offering (3,3)     TLSv1.0   **TLSv1.1 **FAIL    **TLSv1.1

ClientHello (no extensions)   TLSv1.0   TLSv1.0   **FAIL    **FAIL
  client_version=(3,1)

ClientHello (SNI)             TLSv1.0   TLSv1.0   TLSv1.0   TLSv1.0
  client_version=(3,1)

ClientHello (no extensions)   TLSv1.0   TLSv1.1   **FAIL    **FAIL
  client_version=(3,2)

ClientHello (SNI)             TLSv1.0   TLSv1.1   TLSv1.1   TLSv1.1
  client_version=(3,2)

ClientHello (no extensions)   TLSv1.0   **FAIL    **FAIL    TLSv1.2
  client_version(3,3)

ClientHello (SNI)             TLSv1.0   **FAIL    **FAIL    TLSv1.2
  client_version(3,3)

ClientHello (SNI+sig_algs)
  client_version(3,3)         TLSv1.0   TLSv1.2   TLSv1.2   TLSv1.2

The strange SChannel behaviour for SSLv2Hello offering (3,3) affects
MSIE 11 Win 7/2008R2 (and probably Win8/8.1/2012/2012R2 as well).
When "SSL Version 2" is enabled in "Internet Options" together with TLSv1.2
then interop with an TLSv1.2-enabled Microsoft IIS (SChannel) is still
possible, because of the server-side bug to negotiate only TLSv1.1.

But when MSIE offers TLSv1.2 in SSLv2Hello to a server with a correct
TLS implementation, and that server responds with protocol version TLSv1.2,
then MSIE chokes and dies.

  https://support.microsoft.com/en-us/kb/2851628

---

From: Peter Gutmann <[email-masked]>
Date: Sat, 7 Jul 2018 01:34:52 +0000

Martin Rex <[email-masked]> writes:

>I would expect that someone who cares about backwards compatibility would
>test stuff at least once before shipping.

It's not just their TLS code that does things like this.  The Server 2003 SCEP
implementation, when sent a standard SCEP GetCACaps message, would immediately
drop the connection (which at least let you know what server you were talking
to, so it was a sort-of GetCACaps at least).  The Server 2012 SCEP
implementation will respond to a PKCS #1-wrapped (as per the spec) AES-
encrypted SCEP client request with an OAEP-wrapped (completely incorrect)
single-DES-encrypted response.

I cannot even begin to imagine what sort of coding would produce that level of
breakage.  This must have been tested on exactly zero implementations before
it shipped.

>Windows 2008R2 and later looks like entirely untested to me or maybe "tested
>only with MSIE and only in default config"

For SCADA stuff it's only the client side that matters (browsers being used to
admin devices), so I haven't looked at server-side breakage that much.  Even
then, note the comments in my first message about the bizarro fallback dance +
eventual fail to connect that IE goes through.

In any case thanks for posting that list, it's good to have for reference.  I
suspect at least some of that behaviour may be due to the destructive
interaction of too many backwards-compatibility hacks...

Peter.

---

From: Hubert Kario <[email-masked]>
Date: Mon, 09 Jul 2018 12:58:33 +0200

On Thursday, 5 July 2018 04:32:08 CEST Peter Gutmann wrote:
> >minimum. (Chrome enabled far more DHE ciphers than others, so we
> majority of this stuff is running on isolated, private networks or inside
> VPN tunnels for which pretty much anything, including 512-bit keys, are
> fine.

There Is No Such Thing As A Trusted Network

and there wasn't for half a decade at least

If the IPsec is used for p2p security, then the TLS is useless in the first 
place. If there is "last leg" that goes over regular copper or fibre, then TLS 
is providing the security, so 512 big keys are NOT secure

https://cloud.google.com/beyondcorp/
https://blog.cloudpassage.com/2015/10/06/the-end-of-trusted-networks/
and dozens of other articles on the topic

I'll just ignore the fact that no browser has ability to tell if it is 
connecting over such "secure" network or not, let alone making it 
unexploitable for regular Internet connections...

---

From: Hubert Kario <[email-masked]>
Date: Mon, 09 Jul 2018 13:01:45 +0200

On Thursday, 5 July 2018 20:18:27 CEST Martin Rex wrote:
> I'm not actually aware of any problem 

the ones that gave us 20 years of oracles to use for attacking encrypted 
connections

Bleichenbacher and ROBOT, and those are not even /timing/ based attacks!

---

From: "Salz, Rich" <[email-masked]>
Date: Mon, 9 Jul 2018 12:18:40 +0000

>    There Is No Such Thing As A Trusted Network
  
That's a great aphorism, and we've all made lots of progress in working with that assumption, but there are important cases where it is not true.  And I think Peter works in many of those cases.

---

From: "Blumenthal, Uri - 0553 - MITLL" <[email-masked]>
Date: Mon, 9 Jul 2018 13:46:24 +0000

+1 to Rich and Peter.

Regards,
Uri

Sent from my iPhone

On Jul 9, 2018, at 08:20, Salz, Rich <rsalz=[email-masked]> wrote:

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 10 Jul 2018 00:33:19 +0000

>There Is No Such Thing As A Trusted Network

I didn't say "trusted network", I said "isolated, private network".  The type
where, if an attacker has got to the point where they have physical access to
the area where the network is, they can do far more damage via any kind of
non-network attack than they could by hauling in computing equipment and
sitting there for hours or days trying to attack the crypto on a particular
endpoint.

In addition, the security doesn't have to be theoretically perfect, just good
enough.  An isolated network is frequently deemed secure enough, taking into
account the resources being protected, cost to an attacker, likelihood of an
attack via that channel, etc.  It's typically much easier to control access to
a network than to secure every single endpoint on that network, particularly
when half of them are a zoo of ethernet-to-something-else converters (if you
want to see a mess of interesting TLS, look at industrial
RS422/485/Profibus/Modbus/Fieldbus/etc to ethernet converters and TCP
gateways, some of those are examples I've used - anonymously - in previous
messages).

The best example of this, which I've mentioned in the past because it's nicely
illustrative, was a ventilator control that used a 512-bit key for its TLS
(16-bit device, and it took about 30s for the connection to be established,
the key size was chosen because it was all the hardware could handle).

This was perfectly adequate, to get access to it you'd need to break into the
facility, get to a network port, grab the key from the device, break out
again, go away and factor it, break in again, get to the network port, fire up
your attack device, and then... you could switch a ventilator on or off.

You could also do that by walking down the corridor and flipping a switch.

In either case, you've now turned a ventilator in an occasionally-used stock
room on or off.  Even the 512-bit key was overkill.

Peter.

---

From: Hubert Kario <[email-masked]>
Date: Tue, 10 Jul 2018 14:45:05 +0200

On Tuesday, 10 July 2018 08:47:15 CEST Björn Haase wrote:
> > Peter Gutmann wrote:
> >In addition, the security doesn't have to be theoretically perfect, just
> >good enough.  An isolated network is frequently deemed secure enough,
> Mostly in my analysis the assumption of the "isolation" of the network is a
> security-misconception making setups vulnerable. You just need a network
> plug and an own wireless device for making the plant remotely vulnerable.
> While I agree that in most cases permanent physical access to a plant by an
> attacker is unlikely, I consider it clearly feasible for the adversary to
> have short-time access to an installation.

exactly, and plopping down an Ethernet to M2M gateway is something that will 
require access once and doesn't even require a knowledgeable attacker (variant 
of Evil Maid attack essentially)

> BTW, This is actually why we in the ICS business need TLS1.3 with its fast
> options on tiny devices such as X25519 and Ed25519. That's by integer
> factors faster on devices such as the M0 or the MSP430 than all of the
> fastest legacy options, such as P256!
> 
> Yours,
> 
> Björn
> 
> P.S.:
> 
> Also in my perception, we clearly need a PAKE option for ICS use, both as
> replacement for PSK for machine2machine interfaces and for true
> operator-account logins. We currently cannot to rely on a properly
> installed PKI in ICS environments.

given what you said above, it sounds to me, like the PAKE in question should 
use negotiation for group (curve) selection, wouldn't it?

---

From: Peter Gutmann <[email-masked]>
Date: Tue, 10 Jul 2018 13:27:40 +0000

Björn Haase <[email-masked]> writes:

>options on tiny devices such as X25519 and Ed25519. That's by integer factors
>faster on devices such as the M0 or the MSP430 than all of the fastest legacy
>options, such as P256!

How are you going to get TLS running on an MSP430 or even an M0?  You can
barely do anything on an MSP430 (it's enough of a challenge getting a TCP/IP
stack going on that, uIP is a rather clever piece of programming but beyond
that you can barely serve web pages from it), and an M0 isn't much better.

See specifically p.12 of
https://www.cs.auckland.ac.nz/~pgut001/pubs/problems.pdf for the MSP430 (those
slides predate this thread by a number of years, so it's not something I've
set up just for this thread).

I would actually love to see a TLS 1.3 implementation on an MSP430.  As far as
I know it's physically impossible, but if someone did it it'd be both
fascinating and horrifying to see what they had to do to make it work.

In any case it's not the crypto that's the problem, the biggest code and
memory issues are, in order:

1. Certificates.
2. The TLS protocol.
3. The crypto.

where (1) >> (2) >> (3).  That's why I mentioned in a previous message
implementations that use memcpy() for their cert management, which eliminates
(1).  To process the cert / cert chain, you scan the network read buffer for
the string "\x06\x09\x2A\x86\x48\x86\xF7\x0D\x01\x01\x01" and copy out the two
integers that follow, so your cert processing is reduced to a few pages of
code (the thinking behind this is explained on p.23 of the same slide set).

Then you've got (2), which has been getting more and more problematic with
each rev of the spec as more and more options get added with each new rev.
Luckily you can fast-path the single option you want to support, for example
for TLS 1.2 with DHE+RSA you don't need extensions, and if you can do ECC and
see an ECC suite in the client hello then you ignore the incoming TLS
extensions and write back a fixed blob specifying -256 for everything (P256,
SHA256, etc), uncompressed points, and so on.  Another thread mentioned that
you can't do TLS 1.2 without extensions, when in fact you can, you just rely
on the fact that everything supports -256 by default.  (This is also why -LTS
makes the -256 otions a MTI, it's the de facto default anyway).

This is where 1.3 is a problem, not a feature.  It's now got so much MTI
complexity, most of which is completely unnecessary for SCADA, that any minor
gain you might make in the crypto implementation is completely lost in the TLS
protocol implementation overhead.

I don't know how vendors are going to deal with this.  There'll be some tricks
used, like the TLS 1.2 "extension handling", but I don't know about the rest.
My guess is they'll stay with 1.2, in the same way that they're staying with
HTTP 1.1 when 2.0 exhibited the same problems.

Having said that: "Predictions are always difficult to make, especially about
the future".

Peter.