Windows 10.14393.51 vs Logjam

[RobTho]

Windows 10 1607 + August Patch (10.14393.51) shows to be vulnerable again Logjam (IE and Edge).

https://www.ssllabs.com/ssltest/viewMyClient.html show vulnerable https://dev.ssllabs.com/ssltest/viewMyClient.html show NOT vulnerable

Is this a detection bug ?

[ghost]

I guess this is a bug of SSL Labs, because the server sometimes chooses TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite.

[bhushan5640]

SSL Conf for ssllabs.com:10445 (Logjam); same for dev.ssllabs.com:10445

[RobTho]

Same issue today....

DEV:

WWW:

[bhushan5640]

Try connecting these urls and post ciphers selected in negotiation ssllabs.com:10445 dev.ssllabs.com:10445

i.e. click on the the test manually link

[ghost]

I can't reproduce the issue now. They both negotiated TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 with Edge.

[bhushan5640]

If client negotiate with DHE suite with 10445 server its vulnerable. Weak DH params are set at ssllabs.com:10445

I am getting correct /consistent result with dev and prod. Tested with Firefox 32 and 49 Firefox 32 : vulnerable Firefox 49 : not vulnerable

Edge / Win 10 : not vulnerable

[ghost]

@bhushan5640 Oh, I meant the servers specified the DHE cipher suite in their ServerHello (rather than ECDHE in my test yesterday). Then Edge immediately closed the connection. Sorry for the confusion!

[bhushan5640]

I will try if I can reproduce that with Win 10 aug patch. That should not happen ECDHE suites are not configured on that server.

[RobTho]

I tried again today, and now WWW and DEV shows "Your user agent is not vulnerable". Yesterday i was also able to open https://www.ssllabs.com:10445/ (and get the related warning) but https://dev.ssllabs.com:10445/ was not accessable. So i don't think this could be client related. Is there maybe any loadbalancer for https://www.ssllabs.com:10445/ and maybe one of the servers behind is not correcly configured ?

[ghost]

I can reproduce again on https://www.ssllabs.com:10445.

I find that if the Session ID in Client Hello is empty, then the server chooses TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 without any problem. If the client is resuming the old session used on port 443, then the server on port 10445 accepts that session ID and therefore negotiates ECDHE.

Now I think this is a bug in Edge, since I don't think it should send the session ID used by another port, even if they have the same domain name and IP. On the other hand, shouldn't the server on 10445 reject the session ID?

There was a discussion about a similar TLS session resumption issue in TLS Working Group mailing list in 2007: https://www.ietf.org/mail-archive/web/tls/current/msg01414.html. Unfortunately, they didn't seem to reach any consensus on whether browsers may send session ID in this situation.

Another related discussion: https://bugzilla.mozilla.org/show_bug.cgi?id=415196

[ivanr]

That's a very interesting edge case, thanks for debugging it! The solution here should be to use a separate session cache for port 10445 or disable the session cache altogether. The root cause is probably that the ports are sharing a session cache because they're powered by the same web server process. Generally speaking, TLS session cache sharing is a known problem, but it's relatively obscure. In this case, the consequences are breach of cipher suite policy; in other cases, session cache sharing could be used to transfer vulnerabilities from one site to another. The biggest problem is that session resumption bypasses certificate checking. This is the paper that first discussed the problem: https://bh.ht.vc/vhost_confusion.pdf It's largely an implementation issue.

[bhushan5640]

Fixed now on dev https://dev.ssllabs.com/ssltest/viewMyClient.html

[bhushan5640]

disabled session resumption on ssllabs.com:10445. Please report if the issue still occurs.

[RobTho]

Still happens with Windows 10 Mobile 1703 and 07-2017 Patch (10.0.15063.483)

https://www.ssllabs.com/ssltest/viewMyClient.html show vulnerable https://dev.ssllabs.com/ssltest/viewMyClient.html show NOT vulnerable