Thursday, July 28, 2011

SSL Certificate issue: What went wrong

Last week, Comodo , one of the major SSL vendor came under the media controversy for being under attack. Comodo acknowledged that one of their Registration authority had been compromised in an attack on March 15. The attack initiated with compromise in Username and password of their south american partner organisation.
with the hacked username and password, attacker was then able to covertly issue nine digital certificate across seven domains, including:, (NSDQ:GOOG).com, and The company believes
the attack -- which it traced to two IPaddresses assigned to an Iranian Internet Service Provider (ISP) -- may have been an effort by the Iranian government to spy on dissidents using Gmail, Skype and other services. But in addition to opening discussions of possible government spying, the situation also has turned a spotlight on one of the basic issues of the Internet -- proper authentication. “There really has never been an ‘SSL trust chain,''' explained Gartner John Pescatore. “SSL in practice only provides transport encryption -- it does not provide any meaningful authentication of the user and only minimal authentication of the server. It has always been way overhyped by the ecommerce world to try to overcome fears in online commerce
The attack points out a number of issues with the current SSL web of trust. First, the delegated nature of the system means that it is only as strong as the weakest link – in this case the security of the registration authorities. Second, the mechanism for revoking certificates has some serious drawbacks. There are basically two ways for registrars to let users? browsers know that certificates are invalid – one method is called Certificate Revocation Lists and the other is called Online Certificate Status Protocol. In theory, browsers use these protocols to check the validity of each certificate they receive. In theory. In reality, in their default configurations, browsers will allow certificates to be used even if they are unable to get certificate status for them – this is a ?fail open? situation. Should an attacker combine the creation of fraudulent certificates with a denial of service attack against a CA?s CRL or OCSP infrastructures, millions of users browsers would happily accept the fake certs without a peep.
In order to provide users with protection against this attack, the browser vendors had to issue updates to their software which included the bad certificate numbers in the local Certificate Revocation Lists. This puts the onus on the user, and I have seen enough users who don?t bother to update browser software to wonder just how many people are still vulnerable to this attack.
Requiring CAs to maintain robust infrastructures for OCSP and CRL checking by browsers and configuring browsers to require positive CA validation of certificates would go a long way towards fixing this issue in the short term, but such a solution has its own price in terms of privacy. As a result of their certificate checking functions, CAs would become able to track the web browsing habits of millions of internet users. Such a fix would also require a significant investment in infrastructure by the CAs, which could lead to higher prices for certificates..

Monday, July 18, 2011

Some SSL Myths

SSL is still computationally expensive. Improvements in processor speeds in some circumstances have made that expense less impactful. Circumstances are changing.
Commoditized x86 hardware can in fact handle SSL a lot better today than it ever could before –when you’re using 1024-bit keys and “easy” ciphers like RC4. Under such parameters it is true that commodity hardware may perform efficiently and scale up better than ever when supporting SSL. Unfortunately for proponents of SSL-on-the-server, 1024-bit keys are no longer the preferred option and security professionals are likely well-aware that “easy” ciphers are also “easy” pickings for miscreants.
Why does my webserver have a higher load, now that it serves SSL encrypted traffic?
SSL uses strong cryptographic encryption, which necessitates a lot of number crunching. When you request a webpage via HTTPS, everything (even the images) is encrypted before it is transferred. So increased HTTPS traffic leads to load increases.
Certainly if you have only one or even two servers supporting an application for which you want to enable SSL the costs are going to be significantly different than for an organization that may have ten or more servers comprising such a farm. It is not just the computational costs that make SSL deployed on servers problematic, it is also the associated impact on infrastructure and the cost of management.
Why can't I use SSL with name-based/non-IP-based virtual hosts?
The reason is very technical, and a somewhat "chicken and egg" problem. The SSL protocol layer stays below the HTTP protocol layer and encapsulates HTTP. When an SSL connection (HTTPS) is established Apache/mod_ssl has to negotiate the SSL protocol parameters with the client. For this, mod_ssl has to consult the configuration of the virtual server (for instance it has to look for the cipher suite, the server certificate, etc.). But in order to go to the correct virtual server Apache has to know the Host HTTP header field. To do this, the HTTP request header has to be read. This cannot be done before the SSL handshake is finished, but the information is needed in order to complete the SSL handshake phase. Bingo!
The simplistic nature of the argument also fails to take into account the sensitive nature of keys and certificates and regulatory compliance issues that may require hardware-based storage and management of those keys regardless of where they are deployed (FIPS 140-2 level 2 and above). While there are secure and compliant HSM (Hardware Security Modules) that can be deployed on each server, this requires serious attention and an increase of management and skills to deploy. The alternative is to fail to meet compliance (not acceptable for some) or simply deploy the keys and certificates on commoditized hardware (increases the risk of theft which could lead to far more impactful breaches).
SSL “all the way to the server” has a profound impact on the rest of the infrastructure, too, and the scalability of services. Encrypted traffic cannot be evaluated or scanned or routed based on content by any upstream device. IDS and IPS and even so-called “deep packet inspection” devices upstream of the server cannot perform their tasks upon the traffic because it is encrypted. The solution is to deploy the certificates from every machine on the devices such that they can decrypt and re-encrypt the traffic. Obviously this introduces unacceptable amounts of latency into the exchange of data, but the alternative is to not scan or inspect the traffic, leaving the organization open to potential compromise.