Home > Security > Fiddling with Chromium's new certificate pinning
Fiddling with Chromium's new certificate pinning
Posted on 4 Juli 2011 by c0decstuff
Over the past few years, there have been various high-profile incidents and concerns with the Certificate Authority-based infrastructure that underpins https connections. Various different efforts are underway to tackle the problem; many are enumerated here:
http://googleonlinesecurity.blogspot.com/2011/04/improving-ssl-certificate-security.html
And in terms of things baked directly into the browser, we have things like Firefox's Certificate Patrol add-on:
https://addons.mozilla.org/en-US/firefox/addon/certificate-patrol/
My colleague Adam Langley summarized some features and directions we've been exploring in Chromium recently, it's a good read:
http://www.imperialviolet.org/2011/05/04/pinning.html
These features can also be controlled via the command-line, so to give a glimpse of the future, I present to you:
(You'll need to edit a couple of things such as the command name and the temp directory if you're on Windows or Mac).
If you wish to connect securely to Twitter, well it pretty much does so... like a boss. It does the following things and defends against the following situations:
The above command line isn't finished. Although Twitter seems to run fine, there are under-the-hood failures to
Hopefully this demo is compelling. The plan is to push this technology more and more under the covers so that it happens for less technical users who have an empty command line!
http://googleonlinesecurity.blogspot.com/2011/04/improving-ssl-certificate-security.html
And in terms of things baked directly into the browser, we have things like Firefox's Certificate Patrol add-on:
https://addons.mozilla.org/en-US/firefox/addon/certificate-patrol/
My colleague Adam Langley summarized some features and directions we've been exploring in Chromium recently, it's a good read:
http://www.imperialviolet.org/2011/05/04/pinning.html
These features can also be controlled via the command-line, so to give a glimpse of the future, I present to you:
Twitter Like A Boss
Run Chrome (v12 dev channel or newer required) with a command line like this:
google-chrome --user-data-dir=/tmp/chrome_twitter --incognito --disable-plugins --proxy-server=localhost:1 --proxy-bypass-list=https://twitter.com,https://*.twitter.com,https://*.twimg.com --hsts-hosts='{"df0sSkr4gOg4VK8d/NNTAWFtAN/MjCgPCJ5ml+ucdZE=":{"expiry":2000000000.0,"include_subdomains":true,"mode":"strict","public_key_hashes":["sha1/TXoScD1SXPfhmRO8ACTPrkXD9Yk="]},"tGm+XsbBPK211uMWtg2k071vijQkuVLvd62QzfNFol8=":{"expiry":2000000000.0,"include_subdomains":true,"mode":"strict","public_key_hashes":["sha1/06curQTaPH4PGumbNSeL79da23s="]},"wZU3atDOXaxKkaRgSdlWwB4UYjulRq46SGnIBij5I98=":{"expiry":2000000000.0,"include_subdomains":true,"mode":"strict","public_key_hashes":["sha1/O6hykhOmHJ5HQUREC0DTDeu6+mE="]}}' --user-agent='LIKE A BOSS'
(You'll need to edit a couple of things such as the command name and the temp directory if you're on Windows or Mac).
If you wish to connect securely to Twitter, well it pretty much does so... like a boss. It does the following things and defends against the following situations:
- The
--user-data-dir
flag loads Twitter in a new profile so that you get a new Chrome instance and therefore new cookie jar. Therefore, carelessly clicked links in your other browsing windows won't get you XSSed. - The
--incognito
flag applies the usual incognito changes; notably, things like profile photos won't be cached to disk; might be useful if you're an activist. --disable-plugins
is strictly unnecessary since Twitter generally isn't using plug-ins. However, any "secure" command line should likely include that flag.- The
--proxy-server=localhost:1
is a good defensive catch-all which will stop any site traffic being sent by your browser unless it is whitelisted. Specifically, ahttp://bit.ly/
link to an XSS payload won't work on you. (You'll need to paste such links into an alternate browser which shouldn't be logged in to Twitter). This will also stop non-pinned https requests going out (which might otherwise compromise the integrity of the main page). Mixed-content bugs, cookie forcing and failure to mark cookies "Secure" will also be mitigated. --hsts-hosts
is the magic. It locks twitter.com, api.twitter.com and twimg.com such that SSL traffic from/to Twitter will only be accepted if the leaf SSL certificate's public key is exactly what we expect. It's called "certificate pinning", and along with HSTS, it defends against any compromised root CA, Comodo-gate, Tunisia-like sslstrip attacks, and the "evil country owns firewall + CA" situation.--user-agent='LIKE A BOSS'
is strictly optional, depending on your mood.
The above command line isn't finished. Although Twitter seems to run fine, there are under-the-hood failures to
scribe.twitter.com
and other places because I haven't added the correct certificate pin for that host. The above will break if any of the leaf certificate public keys change (this doesn't necessarily happen on expiry rollover but may otherwise happen for various reasons).Hopefully this demo is compelling. The plan is to push this technology more and more under the covers so that it happens for less technical users who have an empty command line!
Category Article Security
Total Pageviews
Labels
- Android (1)
- Aplication (14)
- ARP (1)
- Backdoored (2)
- Browser (1)
- Cloud (1)
- Exploitation (1)
- Exploits (7)
- Facebook (2)
- forensics (3)
- Hacking (11)
- Hijacking (1)
- Honeypot (1)
- HTML5 (1)
- ios (2)
- Jailbreak (2)
- Linux (1)
- Malware (5)
- metasploit (2)
- Meterpreter (1)
- Movie (1)
- Networking (1)
- News (2)
- password attack (2)
- Penetration Test (2)
- Python (1)
- reverse engineering (1)
- Rootkits (1)
- Security (12)
- shellcode (2)
- Stuxnet/Duqu (2)
- Uncategories (1)
- Virus (1)
- Vulnerability (8)
- Web (5)
- Wifi (1)
- Windows (5)
Blog Archive
-
▼
11
(51)
-
▼
Jul
(11)
- Breaking MailEnable 2.34: A lesson in security fea...
- Meterpreters new reverse_http and reverse_https op...
- Capture all metasploit input/output
- Pwning Mac OS X with evilgrade + MacPorts
- reverse engineering the google +1 button-using-fir...
- Advanced Nmap
- Fiddling with Chromium's new certificate pinning
- Journey into Exploitation: awbo2.exe
- Extracting Files from a tcpdump
- How security-teams deal with leaking passwords
- Transfer Files and Data via DNS-Requests
-
▼
Jul
(11)
Friendlist
Security Resources
-
-
-
This feed contains no entries
-
-
-
-
-
-
-
-
-