Hacker News Reader

Comment by jusob | Hacker News Reader

It does not have to be. Done correctly, SSL interception can pass through all the errors to the client:

* certificate issues (expiration, domain mismatch, etc.)

* OCSP/CRL verification

* validation of HPKP header

I understand that few vendors may be doing it (I know one which does at least the first 2). Probably the worst offense is choosing the weakest TLS version + cipher to save resources, like using TLS 1.0 because it take less resources to decode/encode than TLS 1.2 + elliptic curve.

View on HN

> Probably the worst offense is choosing the weakest TLS version + cipher to save resources, like using TLS 1.0 because it take less resources to decode/encode than TLS 1.2 + elliptic curve.

This isn't true. It takes less resources to use ECC. Vendors use TLS 1.0 because they use outdated software they haven't updated in ages.

On the other hand, a MITM proxy can also do upgrade "attacks"(?!), communicating with remote servers over the Internet using a stronger protocol than the clients on the LAN behind it support.

In fact it seems to me that having the validation happening in one place may potentially be easier to maintain than across many different clients' software.

My experience with browser companies vs. proxy software companies is that the browser vendors give a much bigger shit about end user security.

You're assuming people on the LAN can upgrade to recent browsers. A lot of them are stuck on Windows XP. I realize that's a "you have bigger problems" type of scenario, but you also have to play the hand you're dealt.

If an organisation has a large number of networked computers on Windows XP they are going to have more issues than that - having no SNI support is one.

If you have an SSL intercepting proxy then you don't need SNI support on the clients.

If this is an explicit proxy, this is true. But with a transparent proxy, SNI would still be needed to know what domain name is going to be requested.

With HTTPS, the Host: header, which is precisely what SNI was designed as a use-case for, can be used.

But you see the Host header after the TLS handshake, after the certificate was sent. The poitn of SNI is to indicate the host header during the TLS handshake so that you get the right certificate. HTTP with the host header is one layer up. Again, this is for transparent proxy where no CONNECT is being sent.

Do you have any links to how the errors are passed through to the client? Do you mean that they imitate the incoming certificate exactly or send the information by some other method?

Reply on news.ycombinator.com