Does HTTPS prevent Man In The Middle attacks?

Posted on October 8, 2015 by eric

A common belief is that the HTTPS protocol prevents so-called Man In The Middle (MiTM) attacks. Unfortunately, in some circumstances, this assumption is wrong.

HTTPS and authentication

A browser decides whether an HTTPS connection is secure if the two following conditions are verified:

The owner information in the received X509 certificates matches the server name. The subject field of the X509 certificate defines the owner information. If the browser visits the website mysite.com, then the subject of the digital certificate should also be www.mysite.com.
The received certificate must be valid and a Certification Authority (CA) that the browser trusts must have signed it. The issuer field of the X509 certificate identifies the issuing CA.

For instance, the certificate checked by your browser belonged to https://eric-diehl.com and was issued the CA AlphaSSL. AlphaSSL is not one of the Trusted Root CAs of Chrome. Nevertheless, its certificate was signed by GlobalSign that is one of the Trusted Root Certification Authorities.

Inside a corporate network, usually all Internet connections are forwarded to a proxy server that resides inside the corporate Demilitarized Zone (DMZ). This proxy may interact with the connection. The same browser does not verify the same certificate when connecting to https://eric-diehl.com. The received certificate was issued and signed by another CA than AlphaSSL. GNS Services issued the certificate of this CA. GNS Services is one of the Trusted Root CAs that were listed in my corporate version of Chrome.

The proxy acts as a local CA. It generates the X509 certificate for the eric-diehl.com domain and returns this new certificate to the browser. As the proxy signed it with a private key being part of a trusted key hierarchy, the browser validates this certificate. The proxy can perform its MiTM.

Why does it work? The Internet uses the trust listed CA model. In this model, the system manages a list of CAs that it trusts. Indeed, the list contains the self-signed certificate of the public key of each trusted root CA. A self-signed certificate is the certificate of the public key that is signed by its private key. The CAs are independent. Browsers have to access all legitimate websites to offer a satisfactory user experience. Thus, browsers have to trust most existing CAs. Therefore, browsers come with a large bunch of preinstalled public root keys of CAs. Internet Explorer hosts about twenty Trusted Root CAs. Mozilla recognizes more than 120 Trusted Root CAs. Each Trusted Root CA signs other CAs’ certificate. The current Internet ends up with more than 1,500 CA that the browsers trust!

A corporate proxy has two solutions:

It may get a key pair with the certificate signed from one of the trusted CA. In that case, it may use the mainstream browsers without any issue. The certificate must be used for signature.
If it allows only managed devices within its corporate network, the IT department can patch the browsers and add their own root public key as part of the trusted CA. Which is the solution used here.

Is this practice only limited to the corporate network? The answer is no. On my home computers, I use an anti-virus. The anti-virus has a feature called WebShield that attempts to protect against malicious websites. It has an option labeled “Enable HTTPS scanning.” This option is set on by default. The certificate validated by the browser when accessing the same website https:/eric-diehl.com with the option enabled, it is not the genuine certificate. It is a certificate that has been signed by the anti-virus that acts as a MiTM. During its installation, the anti-virus appended its own root certificate to the list of Trusted Root CA.

Is it difficult to install such a solution? Unfortunately, the answer is negative. An open source project mitmproxy provides all that is needed to install such a MiTM.

How to know if there is a “MiTM”?

Fortunately, there is a simple test. In 2007, a new flavor of X509 SSL certificates was created: Extended Validation SSL (EV SSL). Only CAs that have a strictly controlled, documented process to verify that the requester of a domain certificate is the actual owner of the domain can issue EV SSL certificates. Browsers provide a distinctively enhanced display for sites using EV SSL certificates. Usually, they display in the address bar the name of the entity owning the certificate, the name of the issuing CA and a distinctive color (usually green). Websites using EV SSL certificates should be more trustworthy than sites using standard X509 certificates.

Of course, if the connection is under a MiTM, the browser does not receive an EV SSL certificate but rather an SSL certificate. The MiTM cannot generate an EV SSL certificate. Thus, the browser displays a classical HTTPS connection.

Thus the simple test is:

Select one website that uses EV SSL and bookmark it.
Each time, you want to check whether there is MiTM, visit this website and check whether it presents an EV SSL certificate.

Conclusion

The current model of trust of Internet employs hundreds of CAs. This brittle model allows to set-up lawful or unlawful man in the middle attacks. As usual, vigilance is the only solution. Fortunately, a simple test detects this type of MiTM.

Update (9-oct-15): THe GNS Services certificate is not part of the standard distribution of Chrome. Thanks to Jim H. for having spotted this mistake

We know where you went

Posted on July 23, 2015 by eric

Google released a new enhancement to Google Maps. The timeline provides you the complete history of locations of your Android mobile device, i.e., likely you. The history is going deep in the past (2009 if you had an Android phone). The analysis is detailled with even the shops or places you may have visited. It is extremely accurate. It is also linked to Google Photo to display the corresponding pictures you may have shot ta that time.

The timeline is only available to you, or more precisely to the entity that logs into your account.

It is scary. The positive side is that Google does not hide that it tracks all our movements.

The feature is available at https://www.google.com/maps/timeline

Update: The feature can be deactivated under yourf Google account history parameters, It is not clear ifr you simply deactivate the time line feature or Google erases the history.

Smart Bottle

Posted on May 1, 2015 by eric

Diageo and Thin Films have recently demonstrated a smart bottle. The seal of the bottle contains a NFC tag. This tag not only carries unique identity of the bottle, but it detects also whether the seal was opened or is still closed. This smart tag allows interesting features:

As for traditional RFID tags, it enables the follow up of the bottle along the delivery chain.
As it uses NFC, the seal allows a mobile phone app to identify the bottle, and thus create a personalized experience (interesting features for privacy: it is possible to track who purchased the bottle (at the point of sale with the credit card) and see who actually drinks it (was it a gift?))
As it detects if the seal has been broken, it is a way to detect tampering of the bottle during the distribution chain. This may thwart some forms of piracy and counterfeiting.
The tag is also a way to authenticate the origin of the product. It may have interesting application for expensive rare bottles to verify counterfeiting.
It does not yet tell if you drank too much. This will be the next application associated to the smart glass that will detect what you drink and how much

See thinfilm brochure opensense

Opportunistic Security

Posted on January 26, 2015 by eric

Under the lead of Dukhovni (2 sigma), IETF issued an interesting concept: Opportunistic Security (RFC 7435). Currently, communications are either cleartext or authenticated and encrypted. Unfortunately, wide scale deployment of ‘inter-operable’ authentication schemes is difficult. The internet is a good example with hundreds of certification authorities with not all them trustworthy.

With current protocols, if the authentication fails, then either the communication fails or falls back to clear text. Opportunistic security proposes a new approach.

The default state is clear text.
If ever encryption is available between peers, then communication uses the encrypted service. This communication is protected against passive attacks, but still vulnerable to active attacks such as man in the middle.
If ever authentication is also available between peers, then the protocol attempts to authenticate. if successful, it would use encryption with a negotiated session key. This communication is protected against both passive and active attacks. If the authentication fails, then communication falls back to encrypted communication.

The announced concept is that encryption alone, even with deprecated algorithms, is better than clear text. The wide use of encryption would thwart , at least, information collection by sniffing. The claimed purpose is to boost the deployment and use of encryption technologies to prepare the later proper deployment of authenticated protocols.

The idea is interesting. Nevertheless, I believe that a mandatory component would be to indicate clearly to the user in which mode his communication is currently: clear, encrypted, authenticated and encrypted. This would be an indicator of the level of trust associated with the transfer. Unfortunately, the distinction may be difficult for laymen.

When DRM sends personal information in the clear…

Posted on November 4, 2014 by eric

Adobe proposes an eBook reader called Digital Editions. Current version is 4. So far, so good.

Unfortunately, on 7 October, the website “The Digital Reader” reported that Digital Editions 4.0 collected information about the reading usage. The announced gathered data were eBooks that were stored in the reader, eBooks that have been opened, pages that were read, and the order. This information was sent back to the server adelogs.adobe.com in the CLEAR. Thus, this version had two issues regarding privacy:

It collected information without informing the end user.
It sent personal information in the clear. Any sniffer could extract this information.

Adobe answered

Adobe Digital Editions allows users to view and manage eBooks and other digital publications across their preferred reading devices—whether they purchase or borrow them. All information collected from the user is collected solely for purposes such as license validation and to facilitate the implementation of different licensing models by publishers. Additionally, this information is solely collected for the eBook currently being read by the user and not for any other eBook in the user’s library or read/available in any other reader. User privacy is very important to Adobe, and all data collection in Adobe Digital Editions is in line with the end user license agreement and the Adobe Privacy Policy

Obviously this answer is not satisfactory. Last week, Adobe published a revised version 4.0.1 that sent back the information using SSL. Furthermore, in a note published on October 23, 2014, Adobe listed the collected information:

User ID
Device ID
App ID
Device IP
Identification of the book
Duration for which the book was read
Percentage of the book read

The information is collected only for DRM protected eBooks. The aim of this data gathering is used for potential clearing house. Some business models of publishers may be based on the actual consumption.

The lesson is that technologists never learn from the past errors. It is not anymore acceptable that private information is sent over the Internet in the clear. HTTPS is an easy solution to transfer secure data and servers scale properly in our days.

Fingerprinting canvas of browser

Posted on July 29, 2014 by eric

In 2012, Keaton Mowery and Hovav Shacham proposed a new original method to fingerprint a browser using HTML5: Pixel perfect: Fingerprinting Canvas in HTML5. It uses a new feature <canvas> of HML5. <canvas> defines an area of the screen that can be drawn by primitives. The idea is to write a text, ideally a pangram, into a canvas, to retrieve the rendered bitmap of the canvas area (using command toDataURL) and calculates from this image a digest. The expectation was that rendering would slightly differ depending on the operating system, the version of the browser, the graphical card and the version of the corresponding driver. Fingerprinting canvas differentiated users. Furthermore, all modern browsers support HTML5.

Canvas fingerprinting is transparent to the user. It bypasses any cookies protection, any private browser mode… If combined with other fingerprinting parameters such as, for instance, http agent or font detection, the uniqueness of the fingerprint is high. The site http://www.browserleaks.com/ demonstrates the differentiation. Do not hesitate to test with your configuration.

This paper was a nice academic study. This month, Gunes Acar et al. published a paper “The Web never forgets: Persistent tracking mechanisms in the wild.” They studied different tracking methods used by the top 100,000 web sites (ranking by Alexa). They discovered that 5.5% of these sites used fingerprinting canvas! It is mainly used by the “AddThis.com” system. Furthermore, by reverse engineering the AddThis code, they highlighted that AddThis improved the technique described in the seminal paper. For instance, the developers used a perfect pangram, or draw two rectangles and checked whether a specific point was part of the path…

User tracking is an arm race and tracking softwares use the latest academic research results.

Note 1: you can opt out from AddThis at http://www.addthis.com/privacy/opt-out. they put a cookie on the computer to signal the opt out 🙁

Note 2: a pangram is a sentence that uses all the letters of the alphabet. A perfect pangram is a sentence that uses all the letters of the alphabet only once.

Facebook would like to listen to what you listen or watch

Posted on May 26, 2014 by eric

Last week, Facebook announced a new feature in their status update. If switched on, this feature will identify the songs or TV program that it will identify through the microphone of the mobile device. It will propose to share this information with your community (and propose a 30 second free sample of the song or a synopsis of the TV program).

A new example of the use of audio fingerprinting. By default, the feature is switched off. Furthermore, the user decides when to share and with whom to share the information. Thus, in theory, there is no associated privacy issues. The user remains in control.

Facebook claims that it will not share it if you do not want. Unfortunately, Facebook does not precise whether it will collect the information for its own profiling even if the user refuses to share it with friends.

As I’m paranoid and as there is no free lunch… I don’t care as I do not have a Facebook account. Will you use it?

The blog of content protection

A site managed by Eric Diehl

Category Archives: Privacy