Google Chrome Will Soon Detect Man-in-the-Middle Attacks (bleepingcomputer.com)

An anonymous reader writes: Google Chrome 63 will include a new security feature that will detect when third-party software is performing a Man-in-the-Middle (MitM) attack that hijacks the user's Internet connection.... Most MitM toolkits fail to correctly rewrite the user's encrypted connections, causing SSL errors that Chrome will detect. The new Chrome 63 feature is in the form of a new warning screen. This new error will appear whenever Chrome detects a large number of SSL connection errors in a short timespan, a sign that someone is trying -- and failing -- to intercept the user's web traffic. This includes both malware and legitimate applications, such as antivirus and firewall applications. The new Chrome error won't show up for all antivirus and firewall software, but only for those that do not rewrite SSL connections in a proper way, resulting in SSL errors.
Chrome 63 is set for release on December 5, but users can already test it by enabling it in the Google Chrome dev branch.

Comments

Re:Alas poor squid

[scdeimos]

What? How does squid break HTTPS connections? Proxy servers don't do anything special with HTTPS connections - the browsers setup a tcp tunnel using the CONNECT command and from there on the proxy server's just copying bytes back and forth.

It's a given that the usefulness of proxy servers is reducing as the percentage of HTTPS-only web sites increases. Eventually all they'll be good for is caching of apt update packages. But any proxy actually breaking HTTPS connections is itself defective.

SSL protocol

[DrYak]

I don't see why MITM attacks intended to capture information would cause SSL errors {...} I always thought the SSL connection between the victims and the MiTM were pristine, normal SSL connections in their own right. Maybe I suppose if they wanted to modify content on the way through, but even then maybe an application layer error, not an SSL issue. Enlighten me...

ONE of the part of the SSL protocol works by having both end points agree on a common password.

The usual technique used is Diffie-Hellman or Elliptic Diffie-Hellman : it's a special cryptographic way in which two end point can agree on a common random password, and nobody else from the outside is able to guess it. (they have a way to exchange a shared secret).

(it's complicated, but it relies on special system in which you can add things together commutatively, but not separate them :
  - e.g. it's easier to multiply prime number than factor the product.
  - e.g.: elliptic curve maths posses an easy "addition" operation, but no trivial way to do "subtraction".
Each side picks a random number side 1 chooses A, side 2 chooses B.
Then they together publicly pick a common number C.
Side 1 computes A+C and sends it to Side 2
Side 2 computes B+C and sends it to Side 1.
External observers can't separate A from A+C nor B from B+C, they can only observe C and these (n+C) combinations.
Side 1 computes (B+C)+A
Side 2 computes (A+C)+B
- Those above are the same : it's a password that can only be known to them.
- External observers could only do (B+C)+(A+C) which is not the same number (and again they can't remove the extra additionnal C from it).)

So when two end point try to establish a secure connection only they 2 know the password, 3rd parties can't.

So if a MitM tries to intercept SSL traffic, they need to negotiate a password with the server.
But because they can only negotiate password between 2 sides, the MitM can't forward the SSL traffic to the victim user, as the user can only negotiate a *different* password. (because in the above detail, they would have guessed a different secret "B").

So the only way for a MitM to work is for the MitM to negociate a password with the server, and negociate a password with the victim,
and then decrypt-relay-rencrypt-forward the SSL traffic.

Then comes the SECOND part of SSL - certificate :

to make sure that the password you got is actually from the server you intend and not from a MitM, the exchange is also cryptographically signed with key pairs. Only the owner of the secret private key can successful sign a signature that is validated by the publicly known public key.

Thus, when establishing the SSL traffic, the server will also sign its traffic, with a key that is itself signed by a root certificate provider.
By seeing that the traffic has a legit signature, the user's browser knows that it comes from the server and not from someone pretending to be the server.

Then there are only 2 possibilities :

- most of the time : the MitM attempts fail, because they do not have access to the server's secret key, and can't forge the server's signature to pretend to be the server. They can only propose some bogus signature. The victim's browser realises that something is fishy, and it wasn't talking to the server as it though, but was talking to a MitM impersonator all along.
You get a big "Wrong certificate" message on the screen.

- a few key situation : the MitM has a way to forge a false certificate that looks legit (e.g.: they have access to a root certificate provider that will sign such a bogus certificate). This is *only the situation* where the SSL connection itself might look pristine.

BUT... there are counter measures even in that case :
- there are other source that can confirm if the correct certificate was used (some relying on DNS)
- some browser can use "certificate pinning" plugins (Certificate patrol is one such for FireFox) : if suddenly the connection isn't signed by "DigiCert" but by "China's State cert", you know something fishy is happening.