Trying Firefox with CMU Perspectives
The October issue of Information Security Magazine brought CMU's Perspectives Firefox plug-in to my attention. By now most of us are annoyed when we visit a Web site like OpenRCE.org that presents a self-signed SSL certification. Assuming we trust the site, we manually add an exception and waste a few seconds of our lives. I probably wouldn't follow this process for my online bank, but for a site like OpenRCE.org it seems like overkill. Leveraging history appears to be one answer to this problem. That's what Perspectives does. As stated in this CMU article:
Perspectives employs a set of friendly sites, or "notaries," that can aid in authenticating websites for financial services, online retailers and other transactions requiring secure communications.
By independently querying the desired target site, the notaries can check whether each is receiving the same authentication information, called a digital certificate, in response. If one or more notaries report authentication information that is different than that received by the browser or other notaries, a user would have reason to suspect that an attacker has compromised the connection...
"When Firefox users click on a website that uses a self-signed certificate, they get a security error message that leaves many people bewildered," [author[ Andersen said. Once Perspectives has been installed in the browser, however, it can automatically override the security error page without disturbing the user if the site appears legitimate.
The system also can detect if one of the certificate authorities may have been tricked into authenticating a bogus website and warn the Firefox user that the site is suspicious.
That sounds pretty cool. I installed Perspectives and revisited OpenRCE.org. This time I sailed right through to the main page. In the screenshot you can see Perspectives bypassed the Firefox warning.
I can manually review the notary server results to see how they made their decision.
One note: I collected traffic during this event and noticed Perspectives use UDP:
08:20:43.900355 IP 192.168.2.103.60739 > 216.139.253.36.15217: UDP, length 32
08:20:43.900408 IP 192.168.2.103.60739 > 66.232.160.65.15217: UDP, length 32
08:20:43.900432 IP 192.168.2.103.60739 > 209.200.18.252.15217: UDP, length 32
08:20:43.900456 IP 192.168.2.103.60739 > 128.2.185.85.15217: UDP, length 32
08:20:44.015193 IP 209.200.18.252.15217 > 192.168.2.103.60739: UDP, length 233
08:20:44.033771 IP 216.139.253.36.15217 > 192.168.2.103.60739: UDP, length 233
08:20:44.034334 IP 128.2.185.85.15217 > 192.168.2.103.60739: UDP, length 233
08:20:44.044537 IP 66.232.160.65.15217 > 192.168.2.103.60739: UDP, length 233
Here's one exchange in detail:
08:20:43.900355 IP 192.168.2.103.60739 > 216.139.253.36.15217: UDP, length 32
0x0000: 4500 003c 0000 4000 4011 a1f1 c0a8 0267 E..<..@.@......g
0x0010: d88b fd24 ed43 3b71 0028 31c5 0101 0020 ...$.C;q.(1.....
0x0020: 0009 0016 0000 7777 772e 6f70 656e 7263 ......www.openrc
0x0030: 652e 6f72 673a 3434 332c 3200 e.org:443,2.
08:20:44.033771 IP 216.139.253.36.15217 > 192.168.2.103.60739: UDP, length 233
0x0000: 4520 0105 3d1c 0000 2e11 b5ec d88b fd24 E...=..........$
0x0010: c0a8 0267 3b71 ed43 00f1 3200 0103 00e9 ...g;q.C..2.....
0x0020: 0009 0016 00ac 7777 772e 6f70 656e 7263 ......www.openrc
0x0030: 652e 6f72 673a 3434 332c 3200 0001 0010 e.org:443,2.....
0x0040: 036d c8b9 0d28 09dc d349 cc79 7885 fa9a .m...(...I.yx...
0x0050: 6e48 bef4 d548 fc34 3b00 93f9 2c6a e349 nH...H.4;...,j.I
0x0060: d1c8 555b 4a66 7123 0057 79ee a19b 5250 ..U[Jfq#.Wy...RP
0x0070: 4d44 5ce2 811d 3092 93d4 382a be6d a596 MD\...0...8*.m..
0x0080: 53be c708 e235 b791 c358 921e 85f5 31ee S....5...X....1.
0x0090: c4e6 d938 bc52 9251 3675 0ba1 04cb 7c48 ...8.R.Q6u....|H
0x00a0: a667 c9af 3893 3f24 9c55 97f7 ffe7 5e48 .g..8.?$.U....^H
0x00b0: ce7e ea16 42df c532 4b5c 07f1 0ea1 6d0d .~..B..2K\....m.
0x00c0: ebf4 0a77 a318 5e3e 301e c6c5 16ff 7e9e ...w..^>0.....~.
0x00d0: 164e d4e8 89b3 952f 0ff1 b207 c973 a8e3 .N...../.....s..
0x00e0: f757 0c4a 1b8c a768 6601 b0bf 8f0a 7f84 .W.J...hf.......
0x00f0: 8218 6dc5 7a62 c4b4 cfae 4154 a51d 13cc ..m.zb....AT....
0x0100: 4520 7c1a 68 E.|.h
You can see the fingerprint 6D:C8:B9:0D:28:09:DC:D3:49:CC:79:78:85:FA:9A:6E if you look close enough. I'm not sure how I feel about UDP for this system. I'd have to look at the system more closely (maybe even the source code) to determine if UDP is "reliable" enough.
This approach is the future of security. Training the user is never 100% effective, so why not try other methods? We already benefit from this approach if we use systems like Gmail. If enough other users mark en email they receive as spam, the rest of us are far less likely to ever see it. We have to move beyond thinking about point defense and turn towards collaborative defense based on monitoring, the wisdom of the crowd, and reputation.
It's important to remember the problem this approach is trying to solve. The classic case is detecting and avoiding a man-in-the-middle attack against SSL while browsing at an Internet cafe. This approach will not help if someone creates a Web site advertising "avoid foreclosure!" if you visit their SSL-enabled site and enter your credit card details.
Comments
http://www.cs.cmu.edu/~perspectives/firefox.html#source
But to save you a second of peeking at it: The protocol uses UDP. The packets that come back from the notary servers are signed by the notary's public keys to prevent an attacker from forging their contents. The client will retry the request a couple of times to each notary in case of packet loss. It's pretty solid, though it won't retry as many times as, say, TCP would - but we figure that the user is going to get annoyed at more than a few second delay anyway.
We used UDP mostly because it's faster (no three-way connection setup), so it imposes less delay on the user, and it keeps the servers stateless and very low-overhead to run. But that said, we plan on implementing a TCP version in the future, because the UDP packets don't get through some people's firewalls. While the extension detects this (and then tells the user and shuts itself off, reverting to the "normal" annoying warning dialog box behavior), we'd rather that it fall back to using HTTP to retrieve the notary information.
-Dave Andersen
That is great. Will the new version be proxy aware? That is the biggest issue in my production environment.
I'd expect most modern firewalls to pass the traffic fine, too. (Mine would, but I roll my own ala' BSD.) It goes back to my old saying: "Firewalls are to protect me from the world; not the world from me." :)
Roman: Doesn't help at all against things like phishing. I happen to have certain strong opinions about dealing with phishing (e.g., creating some TLDs that have extremely restrictive admissions requirements and for which the browser knows it MUST use some kind of extended-validation cert), but I think the problem is a tough one. We're _only_ dealing with MitM attacks. But the core problem of firefox's handling of self-signed certs is also just about MitM attacks, not phishing attacks. Many serious phishing attacks already have certs for their off-by-a-bit domain so that the user thinks the domain is legitimate.
Kace: We'll stick with UDP, but I think it's clear we need to provide an HTTP fallback for both firewalls and, as Richard noted above, proxies.
We do accept patches. :-)