rwnin@firefox-extension: ./sslvis -h -vvv

[sslvis: firefox extension]
https://addons.mozilla.org/en-US/firefox/addon/158232/


[background]
iirc, the basis for a lot of security assumptions on the modern intert00bz come down to everyone trusting that the CAs will keep their promise to not issue bullcerts (technical term: bullshit certificates).

but it looks like they are issuing them to governments and intelligence agencies:

http://www.wired.com/threatlevel/2010/03/packet-forensics/
http://arstechnica.com/security/news/2010/03/govts-certificate-authorities-conspire-to-spy-on-ssl-users.ars


[not to be a bitch]
i mean, in theory all important comms should go over crypto that you manage and trust... and this can be used for 'good'. but that doesn't change the fact that most people use these communication channels for a variety of reasons with an expectation of near absolute privacy.


[so the theory goes]
they are hunting someone using 'secure' public inet services and wanna do a targeted interception or run some pattern matching on a network near afghanistan to find someone. so they do a network level tap on a choke point in the networks serving the region.


[and?]
the CAs gave em a valid cert, so they plug in their device and they're doin cleartext intercepts on everything going through that region. the cert is valid, it's made out to google or sekritbadguylayer.com or whoever.


[massive qualifier]
so do you think that cert the CA gave some snooping party is an exact match of the legit cert of the one running in production?

i'm gonna guess no for the following reasons:

1) the CA would be completely destroying the trust model (bad for business) if they couldn't revoke the certs
2) maybe they simply can't reproduce a cert they issued because data wasn't kept or conditions can't be reproduced (?)


[not my idea]
hashes are just dang hard for people to pay attention to, cause they're huge random strings. but a few years back at bh/dc someone (kaminsky? ranum? sober? no...) was talking about how you can visually represent that same hash value as a series of colors, and all of the sudden it's really easy for humans to notice when a hash changes.


[soooo]
boiling a hash into a word is what sslvis does, and it's a very similar concept. if you hit gmail one day and your word is 'paradox' when it always used to be 'apple' you can easily notice that those words have changed. normally you wouldn't be alerted to the change because there are no warnings or indicators for changes to another valid cert.


[verification?]
there may be a completely legit reason the cert changed. certs expire, disks fail, load balancers exist, devices change, etc etc etc. that's why sslvis sends the host, domain, tld, and hashword value to an external app server:



the default server is hosted on google app engine and feeds the info into a tagcloud:



it includes a (crappy) search feature which let's you visualize the proportions of the certs other people are seeing in real-time. it is slated to include clouds which show the results over time (vapor tagclouds atm ;).

so if your google word is paradox, and that's what everyone else is seeing for the last hour, you're prolly ok to feel kinda sorta mb privatish... kinda...

but if your google word is paradox and there are no other results or just a couple others there is a stark visual cue in the juxtaposed sizing in the tag cloud... this let's you know you're experiencing an anomaly in your connection, and mb you shouldn't proceed...?



in the img above, it looks like maybe a non-malicious anomaly, since canvas is the normal word for www.google.com from what i've seen... (should prolly implement a word search function)


[communist socialist conspiracy?!?!]
well it kinda democratizes and visualizes the whole CA trust issue. a sort of sunshine for crypto maybe? again, not a new idea...


[sidenote]
what about wildcard ssl certs? in theory this detects them too...?


[erm, privacy?]
yea, there is a definite loss of privacy here. but before anyone rants about it, you kinda need to understand that there are rooms in major network facilities where state actors are tapping massive networks on a massive scale. the fact that you go to ilovefarmanimals.com or someshadysite.com is already potentially known to a potentially interested party, even if the details of what you are doing are hidden in the SSL channel.

oh, well that and you can use regexp exclusions or just disable reporting. by default rfc1918 networks are excluded. a trailing asterisk let's you know that a value wasn't reported.

also, you can choose your remote reporting server in the extension options and the source is available so you can just light up one for your own network (and/or just write your own interface to capture the data, it's just a couple HTTP GET parameters).


[what else can it do?]
well, if you capture ip information you track and geo-locate anomalies in near-real time... that could be kinda cool i think...

it would be pretty easy for the app to report back to your browser that your result is way off from the current norm and actively alert you somehow...?


[kludges?]
well... erm... a lot... but right now the data is exported via xmlhttp requests that fire each time you change focus on the tab, and not for each actual request you make... firing on each request also kinda sucks for sites with frequent requests. keeping tabs on what requests are made and how often is probably the way to go.

(btw, i use a secondary xmlhttprequest because you can't read the public hash for an active connection from javascript easily afaik)

there are more kludges... check it out for yourself, i'm def open to suggestions ;)


[downsides]
you're losing (a ton of) entropy, so there's an increased chance an attacker could find a collision and be really tricky. right? a bigger wordlist and highly efficient hashing algo helps there mb...? it might make sense to just report the actual hash back to the server, or pass it as a sanity-check parameter. not sure what (if any) privacy ramifications that might have.

also the app currently has no anti-fraud capabilities. rate-limiting prolly makes sense server-side, and client-side the user could be subjected to some captcha-esk process that issues a cert to check for humans vs cylons.

the app is currently cleartext comms, so a mitm could mitm you when you use it ;)

oh, and this is all only works if the snoopers aren't getting exact copies of certs, either from the CAs or from a compromised certificate store.


[other?]
there are some bugs and unimplemented features... and the app is still in the sandbox since i'm not done testing and adding features.


[coda]
that's all... for now... :)

statcounter follow-up

so how do you feel about cleartext passwords over inet? anyway, this is a followup from my other post about statcounter passing creds in the clear after you hit their page via SSL... the rub of it is that SSL is up and functional for processing creds, they just don't use it.

so i mailed em, and here's what they said:

As far as the general member log in is concerned, a secure connection is not generally used - our view is that the information in your StatCounter account is not "critically sensitive" in the same way as your online bank account would be. In addition, we have never had a case of anyone's log-in details being stolen.

Basically, since we provide a free service, we have to analyse everything on a risk return basis from the perspective of our members. The extra cost of providing secure log in facilities in terms of increased hosting costs etc would reduce the level of service we can provide to our members and tha vast majority of our members are happy with the system as it stands. This is the thinking behind our position.

The service we provide, however, is 100% driven by our members. So if a large portion of our members voiced their concerns to us in this regard, then this is something we would have to implement.

i think that bit at the end is very cool. kudos for being willing to listen to your user base. so i wrote em back w/ this blurb, and haven't heard anything in a few days:

I completely understand that there is a cost benefit analysis that must be done in regards to any security measure. You do provide a nifty free service, and I'm grateful for it...

My main disagreement w/ the crux of your response comes from the fact that you already have SSL infrastructure in place. You clearly have the capacity to handle the current amt of people who hit https://statcounter, although I'm sure most users probably hit http:// instead.

I have never hosted a site, so I can only speculate, but it seems that the increased cost of doing an HTTPS POST for users who explicitly travel to the HTTPS main page would only moderately increase the amount of bandwidth hitting your SSL devices (considering that most users probably hit HTTP by default).

...

[if you] do your login POSTs as cleartext HTTP, then you should just disable the HTTPS site entirely, because it is wasting money and bandwidth by encrypting the public site and not protecting user credentials...

what do you think? do you use the same username and password for accounts like this? or do you have a different password for every site you visit? do you bother to check if you're on SSL when you're logging into a site? are we worried about sniffing anymore?