5 Replies Latest reply on Aug 18, 2010 12:04 PM by agl

    Google Chrome 6 HTTPS issues


      Hopefully someone can shed some light on this issue.  A user recently updated their version of chrome (that is a seperate issue altogether!)  and now trying to connect to certain sites that use https fail.  The message is:


      Error 128 (net::ERR_SSL_UNSAFE_NEGOTIATION): The SSL renegotiation extension was missing from the secure handshake. For some sites, which are known to support the renegotiation extension, Chrome requires a more secure handshake to prevent a class of known attacks. The omission of this extension suggests that your connection was intercepted and manipulated in transit.


      According to google, https filtering is a no no.  See here http://www.google.com/support/forum/p/Chrome/thread?tid=4cb69b09202ddeaa&hl=en&f id=4cb69b09202ddeaa00048e08f813a92a.


      Is there any way to make this work?

        • 1. Re: Google Chrome 6 HTTPS issues

          funny. reading through the source code of chrome shows that it only affects these sites:


            static const char kStrictServers[][22] = {

                // Removed until we update the XMPP servers with the renegotiation
                // extension.
                // "gmail.com",


          They really expect to maintain a static list of sites coded into the browser?


          Reading through the other posts about this makes me laugh. Every proxy now has SSL scanning, including squid. There will have to be some recognition by the developers that this is very commonplace in the enterprise.

          What chrome has effectively done by enforcing this SSL extension is prevent chrome users from going to google's very own site in about 75% of the (really large) enterprises I deal with.

          One of the reasons enterprises are resorting to SSL scanning is for the specific purpose of preventing data leakage to gmail in the first place.


          Without some conssession on their part, Chrome will never gain enterprise acceptance as a mainstream browser. This is one reason Safari/Mac has never penetrated the enterprise in great numbers (among other reasons).

          I don't think there's much MWG can do about it, but I'm no expert on crypto.


          (The views expressed herein are my own and do not represent McAfee.)



          Message was edited by: Erik Elsasser on 8/25/10 7:22:51 PM CDT
          • 2. Re: Google Chrome 6 HTTPS issues

            The renegotiation extension addresses an important security vulnerability in TLS and this is the beginning of a long and difficult process of deploying the fix. As the other correspondent reported, the list of strict hosts is currently hard wired into the binary. This is just a pilot solution and, over time, we will be increasing the requirement that all connections support it.


            We strongly encourage everyone to implement RFC 5746 and it's very disappointing that McAfee products are reintroducing this vulnerability into connections where both the client and server have been updated.


            In general, the use of MITM attacks against TLS connections dramatically impedes future development of the protocol stack. We are working with vendors of MITM equipment to allow them to achieve the same goals without hitting these issues in the future. McAfee is absolutely welcome to contact me to be involved.

            • 3. Re: Google Chrome 6 HTTPS issues

              @agl - while your statement may be correct on the state of TLS, the reality is we (and I am sure many others soon to follow) will now be removing Chrome from our list of acceptable browsers - until there is a fix or workaround - whether on google or mcafee's part.  That means blocking the download of chrome and preventing the use of chrome through workstation policies and web traffic filtering.  I am really not sure what google is hoping to accomplish here in terms of corporate acceptance by forcing this change with no workaround.


              @erik - it looks like rfc 5746 compliance needs to make it into web gateway.  Is this even possible (Am I oversimplifying the problem)?  Is there any way to see if this is on the radar?



              Message was edited by: jspanitz on 8/18/10 1:53:07 AM CDT
              • 4. Re: Google Chrome 6 HTTPS issues

                Good morning,


                Thanks for the discussion on this topic. This thread is being looked at by the product management team for MWG (me as representative ). I've picked up all your comments and will forward them to engineering to get a statement about the observed behaviour and what is behind this, etc.

                Please do not expect to get any comment about when, what, how as post in this forum. If you are particularly interested in progress, please send me a private IM in this portal,  including your email address and indicating that you are interested in being informed and I am happy to do so via email, but will not post this information here publically.


                thanks for your understanding,


                1 of 1 people found this helpful
                • 5. Re: Google Chrome 6 HTTPS issues

                  @jspanitz: Rest assured that we are painfully aware of the pressure on browsers to ignore security issues and work around everything, irrespective of the long-term consequences. We are not immune to this pressure but nor can we allow it to immobilise all development of the transport layer. For Chrome 6, the hard error may be backed off to a UI indication to give vendors even more time to fix this issue but its deployment remains a pressing need.