Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
×
Chrome Security

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

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.
This discussion has been archived. No new comments can be posted.

Google Chrome Will Soon Detect Man-in-the-Middle Attacks

Comments Filter:
  • I'm not an expert in these things, but I suspect this is another nail in the coffin for homebrew routers. I tried making one, but I found the ostensible benefits either didn't work due to https or were already featured in my four year old Asus router.

    • Re:Alas poor squid (Score:5, Informative)

      by scdeimos ( 632778 ) on Sunday September 10, 2017 @04:54PM (#55170991)

      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.

      • by Sigma 7 ( 266129 )

        But any proxy actually breaking HTTPS connections is itself defective.

        That's why some proxy servers support a form of SSL bump, which rewrites the SSL connection but leaves the underlying content intact. This does require creating a custom root+intermediate certificate, but gets the job done without the browser squacking.

        If I can do it with in my personal proxy server (to cache https sites as I visit them), then malware can do it on any system. I get the green lock symbol, the word "secure", and none the wi

        • I have no sympathy for anyone rewriting SSL traffic so they can cache it/inspect it/whatever. You've created your own MiTM problem right there and deserve to be hacked.
          • by DarkOx ( 621550 )

            Yes wanting to know what my bluray playing is up to when it calls home, makes me a bad person. Check

            • Yes wanting to know what my bluray playing is up to when it calls home, makes me a bad person. Check

              Your bluray player will accept the self-signed cert provided by your proxy as legitimate, instead of expecting the cert of its actual home server? That's possible, but it just means the bluray player software is broken, and if the manufacturer is really trying to do something sneaky, they'll fix it in the next update as soon as they realize someone is looking.

          • Have some sympathy for those of us who work in education. We have a legal requirement to filter and monitor for child protection reasons - if we couldn't MITM, we'd have no choice but to block SSL entirely except for whitelisted sites. Filtering on domain name alone isn't good enough when so many sites feature user-generated content and comments.

          • by Sigma 7 ( 266129 )

            Protip: If someone knows enough about HTTPS to successfully do a MitM without the browser squaking, then they're not likely they're going to be hacked by their own MitM method.

            Modern "hacking" attempts instead rely on other social engineering routes, such as the Punycode URL [xn--80ak6aa92e.com] showing up as "Secure" and on apple.com, with the user being unable to tell if something is wrong. The other common route is using a browser exploit to automatically execute code, as done for two consecutive decades.

            So before you compl

      • Kind of what I meant. I tried it and quickly realized that everything I visited repeatedly was https. Actually enabling a lot of the features you'd get from a homebrew required man in the middle stuff for that reason.

      • by jon3k ( 691256 )
        A lot of proxy's will support SSL/TLS termination. A lot of web proxies support this. You use a GPO to push a trusted root to your users, then you terminate their SSL sessions and create a new tunnel using your trusted cert, then inspect the traffic contents. It's usually called "TLS Inspection" or "SSL Decryption [websense.com]" or something like that. By the way, I'm not making any moral judgement on if this is right or wrong.
  • by jonwil ( 467024 ) on Sunday September 10, 2017 @04:48PM (#55170971)

    This is one Chrome feature I wish Firefox (and browsers that use the same codebase) WOULD copy.

  • error cause (Score:4, Insightful)

    by bugs2squash ( 1132591 ) on Sunday September 10, 2017 @04:50PM (#55170977)
    I don't see why MITM attacks intended to capture information would cause SSL errors. I could see there being errors while breaking into an existing connection or poisoning ARP or whatever nefarious tricks are used to force the traffic through the MITM, but surely Mallory is smart enough not to mangle the messages he wants to intercept and preserve and besides, 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...
    • by Sigma 7 ( 266129 )

      I don't see why MITM attacks intended to capture information would cause SSL errors

      If the Mitm just sees the bits transmitted between two points, there won't be a problem. However, the MitM attack wants the decoded information, and that requires cracking SSL.

      The operating system (or browser) has a set of public root certificates, all of which are used to verify a chain of trust of other certificates. The theory is that the SSL certificate is authentic towards an intermediate certificate, and in turn is auth

      • A certificate that doesn't match the page it is supposedly for or a self signed certificate that isn't part of the browsers trust chain is already detected and reported, what's the news?

        • That Chrome will treat multiple successive errors differently than simple trust chain issues. It's the difference between "This server is misconfigured" and "every server you attempt to access appears to be misconfigured, maybe someone is messing with your connection".

          Anyone in IT would have recognised the problem anyway. Average dumb users are less likely to.

          • So instead of every https-page I visit coming up with red URI bar and "this connection is not secure" warning, I will get a red URI-bar on every https-page I visit and "these connections are not secure" warnings?

            Chrome is trying to find a way to make red alert redder?

            • So instead of every https-page I visit coming up with red URI bar and "this connection is not secure" warning, I will get a red URI-bar on every https-page I visit and "these connections are not secure" warnings?

              No you get a full page alert that something is messing with your system.

              Chrome is trying to find a way to make red alert redder?

              No. There's a difference between getting an alert about a security event and getting an alert about systemic problems on your connection. And that's kind of the point.

    • SSL protocol (Score:5, Informative)

      by DrYak ( 748999 ) on Monday September 11, 2017 @07:46AM (#55173421) Homepage

      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.

  • Will this further break hotel wifi?

    It is irritating enough as it is, with my web browsers screaming about invalid certificates and possible MitM attacks when simply trying to pull up a Wifi login screen.

    • by Anonymous Coward

      Use a vpn

    • Re:Hotel Wifi (Score:5, Insightful)

      by KiloByte ( 825081 ) on Sunday September 10, 2017 @06:30PM (#55171347)

      Will this further break hotel wifi?

      Nope, that hotel wifi is already broken.

      It is irritating enough as it is, with my web browsers screaming about invalid certificates and possible MitM attacks when simply trying to pull up a Wifi login screen.

      Because it is a MitM attack? The motive isn't relevant here: the hotel tries to intercept your SSL session and present you something that isn't your intended destination.

      • Re: (Score:2, Insightful)

        by ShakaUVM ( 157947 )

        >Because it is a MitM attack?

        Yes, I know it is. And if the browser would let me go to the damn page, I could get rid of it.

        >Nope, that hotel wifi is already broken.

        Yes, it is. But it's not a security threat either.

        • But it's not a security threat either.

          And how exactly do you tell a hotel who's 100% honest from one that wants to get some extra dime on the side -- be it in gathering data on visitors, displaying ads, or something more nefarious?

          • Being able to do a one-time override to connect to a hotel login screen doesn't compromise by ability to use https everywhere else, which is my normal means of operation.

        • >Because it is a MitM attack?

          Yes, I know it is. And if the browser would let me go to the damn page, I could get rid of it.

          Go to an HTTP URL. Then the hotel proxy can intercept it without trouble, you can get logged in, then go to the page you actually wanted to visit.

          This is a simple, excellent solution for people who understand what's going on. I have no idea how the other 99% of the population is supposed to use hotel Wifi. Hotels may have to find another approach when the vast majority of the web implements HSTS [wikipedia.org].

          Actually, I think what will really happen is that browsers and/or OSes will do Wifi login page detection. Of

    • The latest versions of Firefox opens a pop-bar telling you that this is probably a Wifi log-in screen and gives your the choice to open the login screen in a new tab so you can connect.

      • Not with this hotels' Wifi, apparently. I have the latest version of the big three browsers.

        I don't dispute that the hotel wifi was probably badly configured, but not being able to disable the security measures just to click through a login screen is bad design on the web browsers' part.

        • Not with this hotels' Wifi, apparently. I have the latest version of the big three browsers.

          that's strange : I actually had the "there is apparently a log-in screen" pop-bar just the day before....

          but not being able to disable the security measures just to click through a login screen is bad design on the web browsers' part.

          On the "bad certificate" page in firefox, you can still click to get the details, then add an exception and make it temporary (just until you've logged in).

          Disabling the security is another possible route instead of the pop-bar (one which was available long before the pop-bar itself).

  • by Anonymous Coward

    Not sure why Google would want to cut itself out from pretty much every fortune 500 company.

    The legal requirements and the diligence duty require big companies to MTM all encrypted traffic.

    Just tested the dev channel, and yep, the warnings make the browser pretty much unusable.

    Farewell Google.

  • by fahrbot-bot ( 874524 ) on Sunday September 10, 2017 @05:02PM (#55171027)

    Most MitM toolkits fail to correctly rewrite the user's encrypted connections, causing SSL errors that Chrome will detect.

    Shouldn't all browsers already detect incorrect encrypted connections and/or SSL errors? Otherwise, what's the point?

    • If browsers complained about SSL errors, questionable, dated ciphers and odd configurations, a lot of pages would be considered "insecure".

      Want proof? Take your favorite webpage and get a report from SSLlabs [ssllabs.com] about it. And if you want more, throw the page against Securityheaders [securityheaders.io], too.

      If you don't mind losing some sleep, try it with your favorite online banking page.

      • Slashdot get's an "A" from SSLLabs (only minor complaints), but and "E" out of "G" for headers (several missing that they want).

    • They do. The difference here is that chrome will detect repeated errors and then show a different warning.

      A MITM attack would otherwise show up as an error on the SSL trust chain. This warning is saying "hey you got a lot of trust issues recently, you sure someone isn't meeting with you?"

  • If people really gave a shit about it, they already could. It is already very possible, with every browser out there, to identify broken certificate chains and bogus certificates. Every single browser out there first displays a "this connection is not secure" warning. Chrome adds a red URL bar with a big, red "NOT SECURE!" next to it.

    You know what really bugged me to no end? That the only thing HSTS added to the mix was that people are now complaining about a page not letting them in because "something is b

    • The problem is that I need to accept self signed certs, SSLv3 certs, etc. from copiers, switches, UPS units, etc.

      Let ME choose. Warn all you want, but let ME fucking choose. I know what I'm doing, you cocksluts.

      • There is a difference between accepting a risk and ignoring a risk. The former is a way to deal with risks, the latter isn't.

        If you make a conscious decision to accept a risk after knowing it, weighing it against the alternatives and eventually coming to the conclusion that accepting the risk is the best way to deal with it, great.

        The problem is that most people don't do that.

        • No, the problem is the browsers are designed with the attitude that the browser always knows better than the user. That's fine for most people, but it really fucks people like me over. At least Google still lets you accept self-signed certs. But if you've got an SSLv3 device all the browsers throw up a hard "NO" and refuse to connect. Firefox used to let you disable the enforcement in about:config, but not anymore. IE used to let you click a few times to expose the advanced option and connect anyway.

  • by 93 Escort Wagon ( 326346 ) on Sunday September 10, 2017 @05:32PM (#55171127)

    Will Chrome warn people about the attempted information interception as it tells them they should log into their Google account before browsing?

    • Each warning will automatically be posted to twitter and facebook, with an option to opt out in chrome://settings.
    • Why would it? The chain of trust isn't broken by logging into your Google account.

      By comparing an MITM to Google's collection it shows you're either trolling, or completely incapable of understanding differences in trust.

  • This includes both malware and legitimate applications, such as antivirus and firewall applications

    It would have been a good opportunity to warn the user about security software that intercept SSL. There is a real security hazard here, as we have no idea how good theses SSL client implementation are. Does it properly validates certificates, for instance?

  • MITM attacks are impossible to detect without physical ownership and inspection of all links and devices along the path.

    • Sure if you assume a perfect attacker. But most are not.

    • MITM attacks are impossible to detect without physical ownership and inspection of all links and devices along the path.

      Perhaps being able to detect "most" or even "some" MITM attacks, if the detection process is low cost, is an improvement.

      • Sure, but I'm more worried about a MITM that has physical access to wires along the path.

        You can't detect or stop that kind of attacker. You can prevent them from reading or altering your packets by using encryption. On today's internet that means trusting the key exchange and cipher negotiation protocols as well as the cipher itself. However, it's also known that that type of attacker typically has the ability to create "valid" certificates for any domain, knows of unpublished vulnerabilities in the pro

    • They are actually quite easy to detect, providing one end has a public key signed by a mutually trusted party. That's what SSL certificates are for.

  • Could Chrome also check CAA and TLSA records in a site's DNS to assure the cert being provided is the one the site owner wants to provide?
  • How often are users actually targeted for MITM attacks? How many have shoddy security applications that handle SSL inspection poorly?

    It's hard to judge the merit without knowing, and I'm betting the balance tips toward the latter. There are a lot of garbage applications out there, even at the enterprise level.

    Because INFOSEC is really: Building a skyscraper with a $5 knock-off multitool.

  • and they say they will use their power to block what they don't want you to see. They'll call what they don't want you to see "fake news", and they'll use a George Soros supported filtering app to make that determination. Facebook Twitter, Bill Gates and FireFox approve of that app so no need to be afraid. /sarcasm

The reason that every major university maintains a department of mathematics is that it's cheaper than institutionalizing all those people.

Working...