SSL Acceleration .info |
Saturday, 31-Jul-2010 14:11:34 GMT |
Security considerations of accelerationBecause SSL is CPU intensive, all SSL servers are prone to denial of service (DoS) attacks. It is relatively easy for a malicious attacker to write software to initiate thousands of client connections to your https:// web site. Your web site will soon grind to a halt. Therefore, having SSL acceleration provides considerable protection. Better, would be appliances that have intelligent heuristics to block promiscuous clients. Many of these devices claim to provide some extra protection over-and-above that of an ordinary web server. In actual practice they will probably add very little. The biggest cost saving will be experienced in that an external appliance is a self-contained and easily understandable thing to those administering your network. An appliance is less abstract that a configurable parameter in some server software and there will be cost savings in managing your network. This is especially true on the rare occasions when things go horribly wrong. An SSL accelerator can provide encryption at higher bit-lengths. For instance, your web server without acceleration might perform badly with 1024-bit RSA. Just imagine how slow it is going to be with 2048-bit RSA. Here is where SSL accelerators can really help. In spite of looming security warnings, however, few are rushing to increase their web site protection beyond 1024-bits. There is good reason not to worry - the kind of resources required to crack 1024-bit RSA could be put to much more damaging use. Uses like thwarting the certificate issuing process, as well as a myriad of other attacks. As of 2008, there is no reason to use more than 1024-bit encryption for e-commerce applications.
General Security of SSLSSL is only one component of a secure system. Certificate vendors are keen to sell you their awesome certificates, but in actual fact, SSL protects against only the most unsophisticated of attacks. About the most we can say is that it is essential that SSL not be absent from any web-site that does e-Commerce. Having SSL and a proper certificate does not even protect against the catastrophic attack of having your web site entirely substituted for a trojan web site so that all your clients start filling that trojan site with all their private data. Exactly how to do this I will not make public here, but it's way cheaper than trying to crack 1024-bit RSA. Here are some of the attacks SSL does not protect against: - Key stroke loggers sent to your clients in malware. - Phishing attacks - using social engineering to get private data. - Trojan sites with miss-spelled domain names. - Insecure operating systems that are hacked. - Insecure web server vendor software that is hacked. - Insecure web applications running on top of your web server. - Insecure network infrastructure appliances that are hacked. - Confidential information hacked out of insecure databases and backup storage systems. - Sites with incorrectly configured domain names so that users are presented with a certificate warning. Users are used to just bypassing this warning - famous example is https://gmail.com/. Statistically many will probably bypass this warning even when a site is a trojan. - Insecure certificate issuance. - Ineffective certificate issuing practices.
Certificates and web site securityI wrote the following section for the article "Public key certificate" on wikipedia.org The most common use of certificates is for https web sites. A Web browser validates that an SSL (Transport Layer Security) Web server is authentic, so that the user can feel secure that their interaction with the Web site has no eavesdroppers and that the web site is who it claims to be. This security is important for electronic commerce. In practice, a web site operator obtains a certificate by applying to a certificate provider with a certificate signing request. The certificate request is an electronic document that contains the web site name, contact email address, and company information. The certificate provider signs the request, thus producing a public certificate. This public certificate is served to any web browser that connects to the web site and proves to the web browser that the provider believed that the provider issued a certificate to the owner of the web site. Before issuing a certificate, the certificate provider will request the contact email address for the web site from a public domain name registrar, and check that published address against the email address supplied in the certificate request. Therefore, an https web site is only secure to the extent that the end user can be sure that the web site is operated by someone in contact with the person that registered the Domain name. As an example, when a user connects to https://www.example.com/ with their browser, if the browser gives no certificate warning message, then the user can be sure that interacting with https://www.example.com/ is equivalent to interacting with the entity in contact with the email address listed in the public registrar under "example.com", even though that email address may not be displayed anywhere on the web site. No other surety of any kind is implied. Further, the relationship between the purchaser of the certificate, the operator of the web site, and the generator of the web site content may be tenuous and is not guaranteed. At best, the certificate guarantees uniqueness of the web site, provided that the web site itself has not been compromised (hacked) or the certificate issuing process subverted. |
|