1

At work, I'm behind an NTLM Proxy. When the SSL Poodle flaw came out, I hardened the configuration of my private server, and found out that even if the client and server shared common ciphers, some configurations led to unsuccessful handshakes. I suspected the proxy to modify the list of supported ciphers and this problem came out again today when a website that I regularly visit stopped working saying that the connection was downgraded to a version of TLS lower than the minimum required by the server, an operation that my web browser wouldn't do.

So I'm wondering, why would a corporate proxy behave like this if it wasn't in an attempt to weaken and spy a connection? I checked the certificates, it doesn't attempt to do MITM attack by issuing fake certificates. Then, what is the point? If I still manage to get an SSL connection, should I consider it secure?

Edit: Seeing the comments, I double checked. The certificates chain and fingerprints are the same as at home. I further checked with my own server where I know what is the real fingerprint (in the unreal case where my home is compromised too :) ) and it is also OK.

Cilyan
  • 183
  • 6
  • 3
    You're _sure_ it's not issuing fake certificates? Check the public keys and see if they're what you expect. – cpast Jan 19 '15 at 19:56
  • 2
    Normally what happens is these proxy servers have fake certs, and the IT department installs the the root CA cert for your proxy. For example, go to Google and see who's signing the cert you get back from Google. If it's not a major CA, you've been MITMed – Steve Sether Jan 19 '15 at 20:30
  • Yes, I really double checked, as I knew SSL Interception was possible. – Cilyan Jan 20 '15 at 21:06
  • Now that I better understand my "problem", I found this question/answer very helpful. Here for reference: https://security.stackexchange.com/questions/71979/how-well-is-the-ssl-tls-handshake-protected-against-modifications?rq=1 – Cilyan Jan 20 '15 at 21:58

1 Answers1

3

I suspected the proxy to modify the list of supported ciphers and this problem came out again today when a website that I regularly visit stopped working saying that the connection was downgraded to a version of TLS lower than the minimum required by the server, an operation that my web browser wouldn't do.

It is not possible to just modify the ciphers within the handshake and leave the rest the same. Since the handshake is protected by a cryptographic checksum this would cause a handshake error because the checksum inside the Finished message (last part of handshake) does not match any longer. For more details see https://security.stackexchange.com/a/20847/37315.

Changes in ciphers can only be done with real man-in-the-middle attack (or SSL interception, which is the same but sounds more friendly), where the man in the middle must change the servers certificate too. This is often done in companies to make scanning of SSL traffic for malware possible. Change of cipher is only a side effect of this, since you have independent SSL connections from the middlebox to the client and another to the server when doing SSL interception.

I checked the certificates, it doesn't attempt to do MITM attack by issuing fake certificates.

The contents of the servers leaf certificate like subject, lifetime etc often gets replicated when doing SSL interception. But if you check fingerprint, certificate chain and trust anchor (root-CA) you will detect the difference.

Community
  • 1
Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • Thanks for the information that the handshake is protected. I didn't know that. I'm starting to believe that it's only the proxy which has some kind of bug and lets the browser think the failure comes from the handshake...? – Cilyan Jan 20 '15 at 21:10
  • I would recommend to make a packet capture to have a detailed look what's going on. – Steffen Ullrich Jan 20 '15 at 21:36
  • @SteffenUllrich Which part of the handshake is protected by a cryptographic checksum? – Steve Sether Jan 20 '15 at 21:42
  • I read further on that topic and my understanding now is that at the end of the handshake, when the connexion is just secured, the first message exchanged is a checksum of all handshake messages received by the counterpart. That way, each part can make sure that during the negociation, the other part received exactly what they sent. @SteffenUllrich if you could update your answer with some more info on that topic, it would actually reply to my question. This is really was I missed to my knowledge to understand the handshake. – Cilyan Jan 20 '15 at 21:49
  • @Cilyan That makes sense. I was reading the RFC myself and curious how the data exchanged could be protected before a secure connection was established. – Steve Sether Jan 20 '15 at 21:58
  • @Cilyan: I made now a short mention of the Finished message but for a more detailed description I've linked to another question where TLS is described in detail. – Steffen Ullrich Jan 20 '15 at 22:12