Tag Archives: ssl

Firesheep Demonstrates The Need For SSL

Posted on by
9

There’s been a storm of discussion over the past 72 hours about Eric Butler’s Firefox extension Firesheep. To summarize, it’s a Firefox extension that facilitates session hijacking by packet sniffing for data from certain websites. As far as software goes, it’s more evolutionary than revolutionary, at its core it’s a packet sniffer. The evolution is the pretty UI which makes it trivial to hijack someone’s session (he really did do a good job on the UI, it’s so easy a child could use it).

It’s actually surprising to me that so many people are shocked by what this demonstrates. Even those who claim to be technically literate seem taken back. Insecure sites by definition are insecure. Anyone can read what’s going across the wire (that includes WiFi) when it is sent unencrypted. If your browser can interpret and use the information to let you browse Facebook, Twitter, etc. so can any browser, on any computer. It’s that simple. Firesheep only supports a handful of sites, but adding support for more sites isn’t difficult. If your favorite website hasn’t been done yet, I expect it will be soon enough.

How Do You Protect Yourself?

The best way to protect yourself is to demand that websites that hold private information use HTTPS from the moment you log in until you log out. Short of that, the best you can do is use a Firefox extension like EFF’s HTTPS Everywhere to force your browser to use HTTPS. This won’t work everywhere as not every web server even has HTTPS working, but many secretly do. They sometimes use HTTPS for certain things like login, then use insecure HTTP for the rest of your visit. That’s so your password isn’t transmitted in plain text. Protecting a password is important, but if the session is insecure anyone can intercept what you do. HTTPS Everywhere works by rewriting all requests to many popular sites to use HTTPS ensuring your privacy and security through the length of your visit. Some websites will have minor issues. For example Facebook Chat is impossible to support right now due to it not working via HTTPS. The rest of Facebook however works.

For more advanced users, HTTPS Everywhere lets you write your own rulesets for sites it doesn’t support.

How Do Websites Protect Their Users?

It’s very simple. Use HTTPS for the period a user is logged in, not just when authenticating and submitting sensitive data. Sure it’s a little slower and requires more hardware, but scaling HTTPS these days isn’t nearly as difficult as it was just 5 years ago. In 2 years it will be even easier. Google went as far as forcing HTTPS upon all of Gmail users. Binding a session to an IP address is fussy and largely ineffective due to NAT, WiFi hotspots and mobile services that can cause an IP to just change with little/no notice. It’s not effective security. It’s better than nothing, but it’s not a fix.

Google could make a huge difference by supporting SSL in Google AdSense, something I’ve called for since 2008. Google has supported SSL with Google Analytics for some time, but they have lagged with rolling out support in other services. Lots of websites monetize with AdSense and this is just another reason websites put off supporting SSL. Other ad networks should do the same. Google AdSense has the least barrier to entry since they serve their text ads off of their own infrastructure, vs. creatives hosted by other parties like some smaller ad networks. One could argue having third-party code inserted on a page mitigates security but it would still be a major improvement over the current state of affairs and would prevent simple session jacking.

The Future Of SSL

Posted on by
Reply

Google announced the other day that it will now enable HTTPS by default on Gmail. Previously a user had to either manually type in HTTPS or change a setting to default to it, something most people likely never bothered to do. Google says it’s not related but it seems oddly coincidental that this chance coincides with its China announcement.

However Gmail using HTTPS is not the big story here.

The big story is that HTTPS is now being used in places where it before was considered excessive. Once upon only financial information was generally sent over HTTPS. As time went on, so did most website login pages, though the rest of the sites often were unencrypted. The reason for being so selective is that it’s more costly to scale HTTPS due to it’s CPU usage on the server-side, and it’s performance on the client side. These days CPU is becoming very cheap.

In the next few years I think we’ll see more and more of the web switch to using HTTPS. If things like network neutrality don’t work this trend could accelerate at an even quicker rate just like it did for P2P using MSE/PE to mask traffic.

Like I said, these days the CPU impact is pretty affordable, however the performance impact due to HTTP handshaking can be pretty substantial. Minimizing HTTP requests obviously helps. HTTP Keepalive is a good solution however that generally results in more child processes on the server as they aren’t freed as quickly (read: more memory needed).

Mobile is a whole different ballgame since CPU is still more limited. I’m not aware of any mobile devices that have hardware to specifically handle SSL, which does exist for servers. Add in the extra latency and mobile really suffers. Perhaps it’s time to re-examine how various Crypto libraries are optimized for running on ARM hardware? I think the day will come where performance over SSL will matter as it becomes more ubiquitous.

Google AdSense And SSL

Posted on by
3

Google’s implementation of AdSense never ceases to amaze me. AdSense has been a major source of revenue for many websites for a few years now and has allowed many businesses to succeed where previously they would have had little chance. It’s a great program and I appreciate how it allows websites to monetize content quickly and with little effort. That said, I’m still so confused by Google’s implementation. It just doesn’t make much sense.

Since July 2007 Google AdSense has had the ability to crawl login protected pages so that it can scan (and therefore provide relevant ads) to pages behind logins. This is great since many pages on sites, in particular social networks where the the majority of page views are post-login can now be monetized.

Despite this progress, Google still doesn’t provide an SSL version of AdSense, so while the page itself can be served over SSL, the ad isn’t. This is problematic since the browser will alert the user that the page is not entirely secure. I really don’t understand why this can’t be done. Google does appear to scan these pages as the ads are relevant, so I don’t think the crawler is the issue. They just don’t want to serve ads over SSL.

Come on Google, the web would be a much more secure place if AdSense supported SSL. It would remove a big reason for sites to not use SSL in places that they should.

For those who would argue that putting third party ads on an SSL page defeats the purpose, that’s only partially true. Yes in an ideal world there’s no third party content on an SSL page. In the real world, Google already supports using SSL with Google Analytics (as do virtually all other analytics services), and you can bet almost any SSL page you access has some analytics on it already. This is no worse. If anything it’s better since unlike Analytics, the nature of the service involves much less recording of user behavior.

By not supporting SSL it’s just encouraging sites to not use it in places where a users privacy and security would be better off with it.

How To Be More Secure With Your Data & Identity

Posted on by
6

It’s amazing how on a daily basis there’s a story about someone’s identity or data being stolen, personal info being misused, or just getting screwed via the Internet. Most of the time it’s due to a complete lack of standards regarding how people treat their digital property and identity. It’s the electronic equivalent of leaving your home and not locking the door. Anyone can come in and take what they want.
Continue reading →

First CVE

Posted on by
Reply

I just found out the other day I found my first bug worthy of being a CVE (Common Vulnerabilities and Exposures) Candidate: CVE-2008-3747. Low profile, but I guess still a potential vulnerability.

I must admit I didn’t know that the database is funded by the National Cyber Security Division of the United States Department of Homeland Security. I did know US-CERT was.

Unobstructed HTTPS

Posted on by
30

There’s an interesting discussion on Slashdot about SSL certificates. It brings up two valid points:

  1. Invalid certificates, while providing a secure mechanism between the client/server are extremely annoying to use in Firefox 3 for many people because of the multi-step process. Previously it was just a warning dialog.
  2. There are no free SSL certificates that are really “usable” (not throwing up warnings in a many browsers). CAcert.org has likely gotten the most inclusion, but it’s barely anywhere.

Certificates not signed by a trusted certificate authority (CA) give up a warning because of the idea that a certificate authority verifies the certificate belongs to the person whose name is on the certificate. This concept was busted a while back as CA’s started doing “domain validation” to offer lower prices. To “remedy” this, they created EV SSL. EV SSL requires more background checking, but at a higher cost. This means there are three tiers of SSL:

  1. Untrusted/Self Signed – Free – The user is strongly discouraged from visiting a site with one of these. Indicates the technologically the channel is secure only.
  2. Signed By CA – Variable Pricing – The user is told this is secure.
  3. EV SSL – Expensive – The user is told these sites are super awesomely amazing and can cure cancer.

Essentially EV SSL is nothing more than a scheme to charge more. EV SSL is supposed to do what a signed certificate should have been doing all along. By 2012 I’d bet there will be a SEV SSL(Super Extended Validation Certificate). Maybe that would require a DNA and fingerprints to prove identity.

The Problem

It’s 2008 (actually more than half way through it). I still can’t use a secure https connection without either throwing up an error to users (who are always confused by it), or paying a fee? It seems right to me it should be free to use https without any barrier for a technical level of security.

Why is “trust” bound so tightly to encryption? Why can’t a medium be encrypted without being trusted? The technology shouldn’t be tied the way it is to the business side of things.

Trust should be bound to encryption, but encryption should not be bound to trust. Trust is the “needy” individual in this relationship. Encryption is strong and confident. At least it should be…

A modest proposal

I propose that browsers should allow for self signed certificates to be used without any dialog, interstitial or other obstruction provided they are properly formed and not expired. The user interface should indicate that the channel is encrypted and communication is unlikely to be intercepted between the user and the server. It should note if there is any change (just like SSH notifies the user if the signature is changed between sessions). Other than that it should be transparent.

SSL certificates and EV SSL certificates should indicate in the user interface the the site being browsed is not only encrypted, but trusted by a third party the browser trusts. These are suitable for ecommerce, banking etc.

This would allow for things like intranets and other places where encryption is desired, paying for a CA to verify identity is overkill, and “domain verification” is just pointless.

Trust should be bound to encryption. Encryption shouldn’t be bound to trust. Encryption shouldn’t require verification. Encryption should be self-serve.

I’d be curious to know what others thought of the issue.

SSL Bug In Firefox 3b5

Posted on by
5

I’ve encountered this bug I just can’t quite figure out, so I figured I’d put it here. Hopefully with a broader audience someone else had encountered it and perhaps this will lead to the root cause being identified.

For some reason Firefox 3 can’t access Webmin on port 10000, which is how it’s setup on a box I have. It worked in Firefox 2.0, but not 3.0. I’m not sure if it’s something to do with Perl’s Net::SSLeay, which Webmin uses for SSL support, or the port number being 10000. I’ve tinkered a little bit with SSL settings, but so far haven’t been able to figure out exactly what’s going on. It seems to be a regression in NSS.

Anyone notice a regression like this using nightly builds somewhere else? This is the only case I’ve personally experienced it. If you have, then visit bug 423499 and let us know.

Edit [5/4/08 @ 11:30 PM EST]: No idea what’s going on here, but apparently nobody else can reproduce, so calling it quits for now.

Using Norton AntiVirus With POP3 Over SSL

Posted on by
Reply

I didn’t find this anywhere online, so I thought I’d post it. Norton AntiVirus up to and including 2007 doesn’t support POP3 over SSL. That’s a problem since sending mail without SSL is insecure, and sending mail over SSL with no virus scanning is also insecure. There is a fix.

Please note these directions, and intended to be a casual guide for experienced individuals. I’m not providing assistance or support.

Continue reading →