Following an interesting discussion on the ZOG security mailing list (which is so elite and secret that, should you be interested in joining a bunch of security guys bashing on Windows and planning beer & pizza excursions, well, enjoy – NO HEADHUNTERS) I thought I’d share my blather on why, frankly, Firefox 3′s self-signed certificate handling sucks.

Don’t get me wrong, aside from the bloat I love FF.  It’s like Apache — it’s a resource hog, but it does what you want nicely, and it’s kind of like a pair of old underpants that you can’t quite bear to throw away.  But this one particular bit of chicanery just stinks.

In case you forgot, when faced with a certificate signed by a CA whose root certificate is not in FF’s certificate store, you receive an obnoxious set of messages (here on a Mac:)

ssl

Oh noes, a cop.  It must be bad!

ssl-1

“Legitimate…other public sites will not ask you to do this.”  Screw you.

ssl-2

“This site attempts to identify itself with invalid information.”

I am doing no such thing.  Rather, I am attempting to encrypt your data transmission.  My site has no reason to identify itself to a client.  Yes, this goes away after the first time, but boy, what a way to scare off potential visitors?

Like Opera, and in contrast to Google Chrome, Firefox does not use any OS built-in certificate stores, such as Windows’ MSCAPI.DLL or MacOS X’s keychain access.  I assume this is for ease of cross-platform maintenance) but it does make it less likely that anyone will use certificates installed universally as part of a Mac package or Windows MSI installer or equivalent.

Thankfully, StartCom Certification Authority is now included by default; CACert, in addition to providing fairly short-lived certs (full disclosure:  I am a CACert assurer of some sort, or at least I was before I completely forgot about it) appears to have failed an audit at one point; Axel Eble points out that Ian Grigg, of Financial Cryptography, is currently conducting an open audit of CACert.

As far as free certificate issuers’ root certificate inclusion in Microsoft products goes, the company’s CA certification policy is pretty hairy — looking at the technical and audit requirements, an open candidate for inclusion in the Windows / Internet Explorer certificate store will have to muster significant financial resources.  Even if this were the case, there’s the interesting catch-all near the end of the requirements, disqualifying

“CAs who fail to meet the burden of proof for the broad business value of their offering to Microsoft customers.”

Without any criteria on what this constitutes.  At least IE’s self-signed certificate warning is a bit less cumbersome.

Commercial certificates cost a fair amount of money, starting at USD $150 for a 1-year basic SSL cert from Thawte, essentially for no incremental cost once they’ve passed their audits.  It’s a money machine, although I can’t fault them for it; I’d try to make money off a broken model too, if I could.

Why is this an issue?  Because the more the use of encryption permeates the Internet, the better.  Call it a distrust of authority, a desire to see increasing amounts of personal data secured out of general principle, a fundamental interest in an overall increase in entropy (let’s not get into the reasons why hiding, obfuscating and protecting your data is necessary — I will simply revert to the old and invincible argument about “you close your door when you use the toilet, don’t you?  What do you have to hide?”)  I want to see everyone and their dog use cryptography, if only for the purpose of letting Joe Schmoe acclimatize himself to the fact that it is not only possible and perfectly legitimate, but actually a very good idea, to encrypt things.

A big scary looking warning creates fear and distrust in the minds of nontechnical users when they visit a site with a self-signed certificate whose purpose is really only to keep the transmission of data-that’s-nobody-else’s-business secure (in addition to being a very small pain in the ass to those of us who have to click through the annoyance every time we want to log into our private web services from a different browser.)  Is that the point?  What about this?

pgp

Nice one, PGP.  Might want to talk to your customer services provider (that is, or at least was at time of writing, their actual site.)

Ian Grigg makes a good point — “I despise and loathe the idea that to use crypto you have to know me.”  As such, I agree with the idea that it’s pretty dumb to combine the handling of credentials used for encryption and identification of sites.  From what I can tell, the latter is Mozilla’s main concern with the hoops a nontechnical user has to go through to make sure a site is “legit.”

I understand the idea of wanting to make it clear that a certificate not signed by a “reputable” CA may be masking a phishing or otherwise fraudulent site.  However, one way around this would be to have two classes of warnings — one a simple check whether the FQDN of the website is identical to that of the host the certificate is created for, with a big friendly easy-to-understand information message stating something along the lines of “this certificate is for host xyz.com, please make sure the address in your browser bar is the same” with a simple list of cautions below it.

Bonus points for separating the authentication and encryption portions of an SSL connection — tell the user “the site claims to be xyz.com but may not be, but your transmission is encrypted, do not enter sensitive data, such as credit card or personal information, unless you’re sure whom you’re talking to” and basta.

The second use case, for certificates authenticating a site and encrypting a connection, should check far more strictly that the issuer is legitimate.  In this case, the end-user has a genuine need to know that the certificate issuance process is tightly controlled via a trusted party — the CA root cert included in the browser store.  Fair enough.

Yes, the average “user” may not have much clue, but excessive mollycoddling at the expense of usability is bound to be counterproductive — it scares people away from increased use of crypto, and annoys the rest of us with way more obstacles than are necessary.

One of my recent projects had me shepherd the development and rollout of an embedded firewall for medical / clinical diagnostic devices in compliance with U.S. HHS / FDA rules on patient data privacy.  Without going into details, a number of new, long-awaited requirements have sprung up within the past few years requiring data protection technology and processes in environments handling sensitive patient information.

This creates a bit of a conundrum for medical device and software manufacturers, insofar as all medical products, not just drugs, must undergo a massive, periodic set of verification and validation tests in order to ensure that they actually do what they’re supposed to, and will not result in minor side effects like genital herpes, limb removal or spontaneous combustion.  Validation is expensive — bringing a drug to market can cost nearly $1 billion;  any changes, upgrades or additions must go through punishing testing procedures.  The same applies to clinical devices — MRI scanners, blood testers, and the myriad of associated machinery — plugs, cables, batteries — anything that somehow processes or plays a role in the processing of patient data.  Fine.

For IT systems, this is a bit of an issue, especially in light of increased connectivity of hospital and other medical products.  When to re-validate?  Software upgrade?  New feature set?  Security patch?  Antivirus pattern udpate?  As we all know, bugs lurk everywhere, and even innocuous changes could bring about unwanted effects in poorly privilege-separated systems.  This becomes worse when consumer operating systems start being used to run task-specific machinery; common development platforms keep costs down and allow for faster and broader-ranging feature implementation, but despite the inevitable whining about security-through-obscurity-is-not-real-security, having an off-the-wall operating system cuts both ways, in that it may hide flaws less likely to be spotted by peer review, but also often requires targeted intrusion attempts in order to break.

So given that clinical validation and revalidation of upgraded software so as to ensure continued reliability can cost anywhere around $500,000 a pop in time, resources and grief, offloading network security is a good thing.  Despite the discrediting of eggshell models of network security (I still firmly believe that any system should be able to survive if exposed on an open network, even if this is not necessarily wise), if it’s simply not feasible to secure everything, you might as well protect it.  The difficulties in validating and maintaining such systems, though, make it desirable to keep things as simple as possible.

Enter m0n0wall and WRAP / ALIX.  This is the most killer hardware/security platform combo I’ve seen.  I have a few of these on the older WRAP board running for years now without a hitch.  They are incredibly robust, simple, without moving parts, and tolerant; my WRAP boards have been dropped, drenched, plugged into massively off-spec power supplies and otherwise abused.  There’s a mini-PCI slot for a wireless card, and newer ALIX boards have VGA-out, sound, USB and serial.

M0n0 has a friendly interface, a great support community and a tremendously motivated developer behind it.  Anyone familiar with basic firewall or crypto terminology will figure it out instantly; it’s fast, lightweight and has never crashed on me.  My only bitch is that changing an inbound NAT rule does not automatically adjust associated firewall rules, but that’s a pretty minor thing.   Best of all, it’s FreeBSD-based and conducive to hacking.

A colleague of mine recently encountered mysterious issues with SSL connections that dropped large numbers of packets, while cleartext pages loaded fine.  After a bit of digging, he found that decreasing his DSL router’s MTU size from 1410 to 1400 seemed to do the trick.

I did some looking around, and found this page from Primus Telecom (Australia) that describes the problem well.

When you access a website or essentially do anything on the Internet, your computer places the information into packets, the size of which is determined by the MTU (Maximum Transmission Unit). On an Ethernet network the default MTU size is 1500 bytes, which is what most routers on the Internet will accept, the problem however occurs when we introduce protocol overheads.

Because there are a number of different protocols your data packets may be encapsulated into, the size of the MTU can increase at different places in the network. If the packet is already close to 1500 bytes when it leaves your ADSL router, it may become larger than 1500 by the time it gets to its destination, which means it will be fragmented, or split up.

Encryption protocols generally can’t handle packet fragmentation, though this is more by design, rather than as a fault, as fragmentation may introduce a point of insecurity, and allow the encryption to be broken or intercepted.

The overhead mentioned consists of datagram encapsulation, for example, and is added by routers along the way.

When using SSL / SSH, the sending machine will set the IP “do not fragment” (DF) header bit to “1″.  Ideally, traffic is sent via the largest size that does not fragment; RFC 1191 describes a technique to use the DF header to discover the PMTU (path MTU, this maximum size.)  Lowering it on first hop after your sending machine will do the trick, though.

© 2010 Chakraborty Software Suffusion WordPress theme by Sayontan Sinha