Home
Welcome. The purpose of
this guide is to clearly explain the reasons you may want to use a Secure
Socket Layer (SSL) certificate on your webserver. While researching SSL
certificates for use on our site we were constantly bombarded by useless
marketing nonsense. What we really needed was a single page with clear and
concise facts. This guide is here to provide an understanding of the basics
involved in deciding what type, encryption strength and seller of SSL
certificates you have access to. At the end of the page are some security
recommendations and known vulnerabilities of SSL implementations.
The primary reason for using a SSL certificate is to encrypt traffic between your webserver and the client with a "trusted" key verified by an independent third party. All communication between the server and the client will be encrypted to protect data integrity. The SSL certificate, when purchased from a "WebTrust Compliant" Certificate Authority, can be independently verified by the client through the CA's servers. Third party validation is the core purpose of a Certificate Authority. It allows the client to have a certain amount of initial trust with a server's domain name.
If you decide to sign your own ssl certificate and not use an independent Certificate Authority then clients will get an error every time they connect to your site. The error will explain that the SSL certificate can not be verified and the site may not be trusted. Even worse, newer versions of Firefox and Opera will now bring up a warning page and not let the user continue unless they choose to.
A certificate bought from a trusted Certificate Authority simply means a client can verify the certificate's validity through a third party. This does not mean the web page data is securely encrypted, does not mean the data on the site is valid and does not mean that the data can not be compromised on the client or server machines.
A SSL certificate simply says that the person or persons who bought the certificate is the same person or persons that own the domain. This is the simplest check done by the Certificate Authority when a certificate request (purchase) is made. The more expensive certs require that the company ordering the certificate verify their legal credentials. This may mean they have to FAX proof of their physical location, their business status (INC, CO, etc.) and contact information to the Certificate Authority and comply with an investigation. This extended verification process is expensive and can take weeks to complete.
A Certificate Authority (CA) is the third party the remote client browser will use to verify your SSL certificate against. An example of a CA is a company like Verisign, GeoTrust or GoDaddy.
When connecting, the client will negotiate (handshake stage) with your web server and your server will send the public SSL key to the client. The client will then connect independently to the CA to verify the certificate's authenticity. Once verified the client will negotiate with your web server to establish a secure connection using SSL encryption. Only then will the client display the "lock" symbol in the browser's URL bar indicating a secure connection has been made.
When purchasing a certificate it is vitally important to make sure that the company you are purchasing from is "WebTrust Compliant" and their servers are listed in the Verification Module for every web bowser.
What is involved in being "WebTrust Compliant" ?
The WebTrust Program is an international e-commerce trust program developed and managed jointly by the American Institute of Certified Public Accountants and the Canadian Institute of Chartered Accountants. You should question any and all SSL certificate providers who do not display the WebTrust seal. Most of the primary certificate providers own their own root certificate. You should verify that the CA your are going to use has their own servers for speed purposes. Every client who connects to your servers will connect to your CA's servers.
WebTrust is an independent auditing process run under AICPA (American Institute of Certified Public Accountants) guidelines designed to address customer concerns about privacy, security, and business practices and signifies that the certificate authority meets independent standards for the issuing and managing digital certificates.
WebTrust is a comprehensive, thorough review by qualified independent specialists which meets or exceeds the US industry consensus standards for privacy established by the Online Privacy Alliance. The program also substantively meets the standards for the European Union and Canada. WebTrust includes both privacy and security but also includes confidentiality, transaction integrity, business practice disclosures.
In order to maintain compliance the CA is required to undergo a program of continuous scrutiny with formal reviews at least once every 6 (six) months. WebTrust compliance is publicly signified by the internationally recognized WebTrust seal of assurance which is displayed on our web sites.
Should we buy an expensive SSL Certificate from a well known Certificate Authority ?
No, you do not have to. The more expensive certs (EV) cost upwards of $500 a year. You can find standard (turbo) certs for as little as $15 a year or even for free at CAcert.org. But, it really depends if you are purchasing a SSL cert and encrypting the data because of your business plan or if you just want encryption for a personal site. If you own a business then the purpose of encryption is for financial safety and public confidence proposes. For this reason you will probably want to go with a more recognizable and expensive certificate authority like Verisign or GeoTrust.
If you are simply using a SSL certificates for a personal site or small business then your only concern is whether client browsers (Firefox, IE, Opera) have the root certificate server in their "Builtin Roots Module" list. For example, to view all of the BuiltIn Certificate Authorities in Firefox v2.x goto "Edit", "Preferences", "Advanced", "Encryption", "View Certificates" and "Authorities". This will show all of the pre-verified CA's by company name that the FireFox developers built into the browser. Our site, Calomel.org uses a cert from "The Go Daddy Group, Inc.". When you connected to this site's server your browser also connected to the GoDaddy servers to verify our SSL identity.
Only buy a certificate from the CA members listed in the browsers "Builtin Roots Module". If you do not, then client browsers will display an error every time they connect to your site due to the fact the browser can not verify the CA's server identity.
What about ancient browsers ?
This also brings up a question involving very old browsers. Newer Certificate Authorities may not be listed in the "Builtin Roots Module" of older browsers. Thus if a client is using IE4 and connects to your site they may get a SSL warning because your new CA, like GoDaddy for example, is not known by their old browser. There is really nothing that can be done on your server about this other than purchasing your SSL cert from a very well established CA like Verisign. They were around during the beginning and the Verisign root servers can even be found in browsers as old at IE4 and Firefox v1.0. It just depends on your interest in supporting ancient clients. At Calomel.org we have made the decision not to support old browsers due to their inherent security flaws. This not only simplifies our setup, but most importantly protects users by suggesting that they update their browsers to help themselves.
Remember, the yearly costs the certificate authority charges has absolutely nothing to do with the encryption of your data. The money you pay only allows a remote client to verify that your SSL certificate has been verified by a third party. The amount of background checks depend on the CA, but it normally means that the owner of the domain is the same owner of the SSL certificate. More thorough checks for the Extended Validation (EV) SSL Certificates also verify that a company is in good standing, is incorporated and verifies the company's physical location including legal contacts.
Are Extended Validation Certificates (EV) that much safer ?
Sadly, No. There has been some concerns lately that EV certificates, despite their improved authentication, company background checks and significantly higher cost, will not prevent phishing attacks.
In 2006, researchers at Stanford University and Microsoft conducted a usability study of the EV "green URL" display in Internet Explorer 7. The study measured the user's ability to distinguish real sites from fraudulent sites when presented with various kinds of phishing attacks. They found that there was _NO_ significant difference between users who saw extended validation indicators and those who did not.
Even worse, when users then received training with the Internet Explorer 7 help file they were more likely to judge _ALL_ sites legitimate, regardless of whether they were fraudulent or not.
It's more likely that users who actually noticed the green URL will learn that the marker isn't reliable and start to ignore it. Most users do not even pay attention to browser warnings; clicking on the "OK" or "Next" buttons blindly.
Brief history of 3DES and AES
Single pass DES was first developed in 1977. DES performs bit manipulation in substitution and permutation boxes in each of 16 rounds. DES encrypts data in 64 bit block sizes which effectively use a 56 bit key. 56 bit key space amounts to approximately 72 quadrillion possibilities. Even though this seems like a lot of permutations, todays computers are powerful and cheap enough to break this cipher in minutes.
Because DES was widely available, the quick solution at the time was to introduce 3DES which was "secure enough" for most purposes. 3DES is the simple construction of applying DES three times in sequence using three different keys (K1, K2 and K3) and has an effective key length of 168 bits. Wikipedia on DES has more examples.
In 2001, a modified version of the Rijndael algorithm was selected as the Advance Encryption Standard (AES) to replace 3DES. Rijndaels combination of security, performance, efficiency, implementability, and flexibility made it an appropriate selection for the Advanced Encryption Standard (AES).
By design, DES and therefore 3DES/TDES, suffer from slow performance in software even on modern processors, AES tends to be around six times faster. By design AES is faster through software and efficient in hardware. It works fast even on small devices such as smart phones, smart cards etc. AES provides more security than 3DES due to the larger block sizes and longer keys. AES uses 128 bit fixed block size and works with 128, 192 and 256 bit keys. Wikipedia on AES have examples and logic charts.
According to NIST, AES is the replacement for 3DES and both ciphers will coexist until the year 2030 allowing for gradual transition to AES. Even though AES has the theoretical advantage over 3DES for speed and efficiency in some hardware implementations of 3DES may be faster where support for 3DES is mature.
Using AES for the SSL key and allowing both AES and 3DES for the handshake
AES is the stronger encryption type and we want to use this to make our SSL certificate. But, we need to allow 3DES as well as AES handshakes so older browsers like Internet Explorer 6 and BOTS like GoogleBot and MSNbot can connect.
How to request a SSL certificate from a Certificate Authority (CA)
When you choose a certificate authority and go through the purchase process they will eventually ask for a Certificate Signing Request (CSR). This is a public SSL key you will provide to them, they will sign it and send a copy back you for use on your server.
To make a CSR key for on Linux or BSD for Apache, Lighttpd or Nginx use the OpenSSL binary. The following will make a 256 bit AES key using a 1024 bit key length. This is the strongest key with the strongest encryption supported by 99% of the browsers and search BOTs. When the private key is made it will ask for a pass phrase. Enter any string, sentence or phase you want that is greater than 8 characters (longer the better and spaces are accepted). The pass phrase will be like a password and you will need to type it in to start any web server using the SSL key. You do have the option of just hitting enter and not entering a passphrase, but this is not considered good security.
root@mach$ openssl genrsa -aes256 1024 > server.key Generating RSA private key, 1024 bit long modulus ................++++++ ..........++++++ e is 65537 (0x10001) Enter pass phrase: Verifying - Enter pass phrase:Now that the private key is made we need to make a public CSR key. This is the key we will supply to the certificate authority for their verification and signature. When you make the CSR key you will have a few questions to answer. It is a good idea to fill out this information truthfully because the Certificate Authority will verify it against their findings. If the information does not match they may deny your request. It depends on your CA, but the majority of the time the information entered in this CSR file will not be made public.
The following scrollable window has an example of the questions you will be asked. The "Organizational Unit Name", "Email Address", "challenge password" and "optional company name" are not absolutely necessary and can be left out if you choose.
The most important question is the Common Name and it MUST equal your domain name your webserver runs as. When remote clients connect to your domain name, lets say "www.mydomain.com", they will make sure the domain they connect to equals the Common Name in the CSR key. If the two do not match the client will produce an error to the user.
root@mach$ openssl req -new -key server.key -out server.csr Enter pass phrase for server.key: You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) []:Country State or Province Name (full name) []:State Locality Name (eg, city) []:City Organization Name (eg, company) []:Company Organizational Unit Name (eg, section) []: Common Name (eg, fully qualified host name) []:www.mydomain.com Email Address []: Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:If you look in your current directory you should see both the server.key and server.csr. Now we need to send the server.csr to the Certificate Authority. Every company is different, but most will allow you to copy/paste the contents of the server.csr into a web page application box. The output of your CSR key should look something like the following format:
-----BEGIN CERTIFICATE REQUEST----- MIIBkTCB+wIBADBSMQswCQYDVQQGEwJVUzELMAkGA1UECBMCTUQxDTALBgNVBAcT BENpdHkxEDAOBgNVBAoTB0NvbXBhbnkxFTATBgNVBAMTDG15ZG9tYWluLmNvbTCB nzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEAyMUWNj9T4fyPhls573vU7/RO5e2O ZZpDuBqXqicUNUxYJWPkjkEhM28z+rSZJt0KuvuNdfMPAcaZSHH/IVWfd36CIwOz dbdG8dQja1lhQN91mceTCtXCi9MkojpKmNeo8jFnoqEMEV3KL3/6upFfLQWQsF5I bLDUrPfrrKRlvHUCAwEAAaAAMA0GCSqGSIb3DQEBBAUAA4GBAGXeAT/niVJfgxFH 7zC10k6hCaiGlOlFCTONaKAN71P4qg4fJ7VxAAFaob1shOxV6vPjd9Q85rPV5qxU orQ+ytxYdO8YbAwTBEMAGQcQM1+lSyeXZNyBnTigkqtaXNDkZRZETgQFuXa19ykn nUx+yXPT6gMoK/2MuH4RIir44DIM -----END CERTIFICATE REQUEST-----
Once you submit your CSR public key to the CA company they should send you two files; probably by email. These two files will be your domain's "crt" file and a bundled "crt" file from the certificate authority. Your domain's crt file will be the certificate signed for just your domain name. The bundled crt file will be for all of the CA's verification certificate servers.
At this point the generation of the certificates are done. Make sure you back them up, do not loose them and do not let anyone else have them. You now need to decide which web server you are going to use and how to configure SSL to work with that server.
The following topics cover the technical details of SSL
Understanding the SSL handshake process
When a client connects to the server there is an encrypted handshake. During this time both systems use an initial cipher to securely negotiate the later use of your SSL certificate. You should make sure to use the most compatible, as well as the strongest ciphers available to your server for the majority of the clients that will connect. AES is the best cipher, but older clients like IE6 and BOTs like Google and MSN do not understand this cipher handshake yet. So, to allow 99% compatibility of the clients to be able to connect to your server make sure to use 3DES and AES handshake ciphers. Most web servers know this as the "HIGH" cipher level.
How the SSL handshake works
The handshake is the key process for a client and server to exchange authentication and encryption information under SSL or TLS. Essentially, SSL consists of two phases corresponding to two sub-protocols. The SSL Handshake Protocol governs the first phase to establish secure communication. Subsequently, all messages are encrypted and exchanged using the SSL Record Protocol.
- Establish the identity of the server by connecting to the domain.
- Develop a shared encryption key that can be used to exchange messages, called the session key. Remember that GoogleBot and MSNBot only understand 3DES handshakes at this time. Yahoo does AES handshakes without issue.
- Client: Hello, here is a list of encryption algorithms I know.
- Server: Hello, here is the algorithm I chose from your list. Also, here is my certificate and public key. If the server does not accept any of the clients algorithms (perhaps they are too weak) then the server will send an error 400 and close the connection.
- Client examines the certificate and makes sure it is signed by a known certificate authority (CA).
- Client: OK, here is the pre-master secret encrypted with your public key.
- Now both client and server can use the pre-master secret to compute the session key: the encryption key for subsequent messages. Normally the server and client keep using this session key until traffic stops. At this point the key will time out in 300 seconds (5 minutes). Any traffic requested after the timeout will automatically renegotiate another session key.
- Client: [encrypted] I'm finished with the handshake.
- Server: Got it. Expect an encrypted reply.
- Server: [encrypted] I'm finished with the handshake.
- All subsequent messages are encrypted with the server's SSL encrypted key.
The handshake: List ciphers of protocol version SSLv3 and keys of 128 bit or higher (HIGH:!ADH:!MD5).
To find out what ciphers your machine will support you can query OpenSSL using the ciphers argument. We highly suggest using SSL version 3 as version 2 has vulnerabilities. Finally you can ask for all ciphers that use the HIGH cipher strength meaning ciphers of 128 bits or higheri, but without anonymous DH or MD5.
root@mach$ openssl ciphers -ssl3 -v 'HIGH:!ADH:!MD5:@STRENGTH' DHE-RSA-AES256-SHA SSLv3 Kx=DH Au=RSA Enc=AES(256) Mac=SHA1 DHE-DSS-AES256-SHA SSLv3 Kx=DH Au=DSS Enc=AES(256) Mac=SHA1 AES256-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(256) Mac=SHA1 EDH-RSA-DES-CBC3-SHA SSLv3 Kx=DH Au=RSA Enc=3DES(168) Mac=SHA1 EDH-DSS-DES-CBC3-SHA SSLv3 Kx=DH Au=DSS Enc=3DES(168) Mac=SHA1 DES-CBC3-SHA SSLv3 Kx=RSA Au=RSA Enc=3DES(168) Mac=SHA1 DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1 DHE-DSS-AES128-SHA SSLv3 Kx=DH Au=DSS Enc=AES(128) Mac=SHA1 AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1Each column in the "openssl ciphers" command mean:
- Official encryption name
- SSLv3 is the secure socket type
- Kx= key exchange
- Au= authentication
- Enc= encryption with bit size
- Mac= mac encryption algorithm
The "@STRENGTH" string is used to sort the current cipher list in order of encryption algorithm key length (256, 168, 128) from strongest at the top to weakest at the bottom. In truth, AES 128bit is significantly more secure than 3DES 168bit.
The default SSL ciphers on Apache, Lighttpd, Nginx are weak
Make sure to specify the ssl ciphers your webserver is going to use in its configuration to at least the "HIGH:!ADH" level. iThis means AES and DES keys over 128 bit, but _not_ anonymous DH keys. Most web servers try to be as compatible as possible by default and accept 40, 56 and 80 bit DES keys. These are incredibly weak and are labeled as acceptable according to US Export control laws. We highly recommend denying weak ciphers by only accepting 3DES/TDES and AES ssl cipher handshakes of at least 128 bits and above. Once GoogleBot and MSNbot start accepting AES handshakes then we can finally limit our ssl ciphers to "AES" only. According to NIST, 3DES is supposed to phased out by 2030.
The path and query string is encrypted in an HTTPS "get" request (this is where form field responses or program variables are tagged on to the end of the URL). These fields are stripped off of the URL when creating the routing information in the HTTPS packaging process by the browser and are included in the encrypted data block. The page data (form, text, and query string) are passed in the encrypted block after the encryption methods are determined and the handshake completes.
A related issue that frequently comes up is whether or not form data is transmitted with encryption if a blank form is displayed without HTTPS. If the form "action" is set to use HTTPS then the ssl handshake will take place before the data is sent. Whether or not the original form is displayed using HTTPS has little to do with the form submission unless the form action uses a relative path, in which case the default will be to use the protocol that was used to display the form. This applies to both the request and the response.
Server Bandwidth considerations are not an issue for most small or medium sized businesses. SSL transactions will increase by about 1 kilobyte per client action and about 5 kilobytes the first time a client negotiates the SSL connection with the server.
Server Processor usage is increased with SSL connections but this should only be a concern on servers running hundreds of transactions per minute. A small business with 10 transactions per minute using AES256 encryption can easily run on a 1GHz server with a load average of .30 .
Server RAM usage is not seriously affected as SSL encryption. The only ram that is used is to save the client/server negotiated session information for a default 300 seconds. Unless you have hundreds of connections per minute a machine with 1 gig of ram should work fine.
Setting the Expire and Cache headers on the webserver for SSL encrypted pages will allow a client to cache the pages in RAM only. For security reasons, pages that are sent encrypted to a client browser will NOT be cached on disk. This is a security/privacy directive set on the client's browser and can not be changed by a web server. You may notice if you look at the "page info" through a browser that the "Expires" field is blank. This is simply because the client will not save a copy of the page to disk. A copy of the page will stay in the clients RAM until it expires, is cleared out for space considerations or when he browser is closed; which ever comes first. If you would like to check the headers on the command line you can use the binary "curl -I --compressed https://localhost".
Yes. The most popular bots will index SSL encrypted pages if they are allowed to in your robots.txt file. For example, type in "site:calomel.org" into a Google search and you will see they already know about our HTTPS pages.
What you have to remember is that all the bots will read AES encrypted pages encrypted using the AES256 bit SSL key, but Google and MSN will _NOT_ negotiate using an AES handshake. It is important to make sure that your web server allows both AES and triple DES (3DES/TDES) handshakes so GoggleBot, MSN bot and IE6 can connect. This is accomplished by allowing "HIGH:!ADH" grade ssl ciphers through your web server.
If I use SSL on my pages, will we be PageRank'd higher then non-ssl pages? So far, there is NO conclusive proof that a SSL site will get higher Google/MSN/Yahoo search rank listing compared to the same site which is unencrypted. In fact there seems to be no positive or negative result if you have your pages encrypted or not. This is because the quality of the data on the site is not validated by SSL, only that the certificate is independently verified. The most important factor in Google's PageRank for example is the amount of high quality sites linking back to your site. The idea being that if a site like Digg or CNN link to your site then your page rank will increase because their page rank is high. This is completely independent of whether your page is encrypted or not.
No. All data on a SSL encrypted page MUST be encrypted. The data can come from multiple servers and multiple SSL certificates, but all data MUST be encrypted.
If we SSL encrypt our pages then receiving clients expect ALL data loaded from that page to be encrypted for security. If there is any data in the clear text, like ads or Java script loaded from an ad server, then the client browser will warn the user that "some data was sent un-encrypted". The browser's URL bar will not turn yellow(ssl) or green(EV ssl) and the little lock symbol will have a diagonal line through it meaning the page was NOT fully encrypted. Now, the remote user is not sure if the transmission of their data is safe and thus does not trust your site. This completely defeats the purpose of having a SSL certificate and page encryption.
If you expect to serve ads, Google analytics or any Java script on your page that loads in the clear from a third party then do not make those pages encrypted.
The Online Certificate Status Protocol (OCSP) is used for obtaining the revocation status of an X.509 digital certificate. In most browsers you can enable OCSP to check with a third party server if the SSL certificate your are negotiating with is still valid.
Internet Explorer starting with version 7 on Windows Vista (not XP) supports OCSP checking. All versions of Firefox support OCSP checking, but it is disabled by default. Firefox 3 will enable OCSP checking by default. Safari on Mac OS X supports OCSP checking. Later versions (after 2008) of Opera support OCSP checking.
We suggest enabling OCSP in your browser. It is not a solution to phishing attacks, but simply another layer of verification.
Note, the criteria for issuing Extended Validation (EV) certificates do not require Certificate Authorities to immediately support Online Certificate Status Protocol for revocation checking. The requirement for a timely response to revocation checks by the browser has prompted most Certificate Authorities to implement OCSP support. Section 26-A of the issuing criteria requires CAs to support OCSP checking for all certificates issued after Dec. 31, 2010.
Although SSL/TLS protocols offer a high level of security in theory, its actual implementations may be vulnerable to several types of attacks. Of the many attack vectors, these are worthy of special attention:
Man in the middle (MITM) attacks .:. In this type of attack, an intruder intercepts the traffic that is being sent between a client and server, such as by forging DNS replies or by performing ARP redirection. Then, it impersonates the client to the server, and vice-versa. During this attack, the user's web browser does not connect directly to the destination server, but instead to the intruder host, which impersonate the web browser and essentially acts as a proxy.
There is good and bad news for an administrator who wishes to defend against such attacks. The good news is that the web browsers warn users when the web server's identity cannot be verified, which may indicate possible man-in-the-middle attack, by displaying a message window with a warning. The bad news is that in real life, users very often ignore such warnings. Hence, if the user's web browser accepts connections to SSL web sites that identities cannot be checked, we can only rely on users' education and trust that they will not press the "proceed" button, if such warning message has been displayed.
Brute-force attack on the session key .:. This attacks can be performed when the intruder knows or can assume part of the clear text that was sent during SSL/TLS session, such as (such as "GET / HTTP/1.0"), and the intruder can eavesdrop this session (such by using tcpdump, Ethereal or other tools). Then, intruder can encrypt the assumed part of the text by using every possible key, trying to find its occurrence in the originally encrypted SSL/TLS traffic. Once such an occurrence has been found, the key that was used to encrypt this part of the message can be used to decrypt the rest of originally encrypted SSL/TLS traffic.
The good news is that maximum number of keys that must be checked is 2^128 when 128-bit symmetric cryptography has been used. Today this is believed to be strong enough to protect the session for literally dozens of years. However, since CPUs grow in strength every year, we cannot really predict for how long 128-bit symmetric keys will be considered to be secure, particularly for hackers with access to large supercomputers.
In case of export-class cipher suites (40-bit, and in some extended 56-bit ciphers) such brute force attacks can be successfully performed in a reasonable amount of time -- sometimes even in few days, depending on the available number of CPUs. If export regulations in your country allow for the use of strong cryptography, one should definitely use it instead of export-class cipher suites.
In addition to the two types of attacks listed above, there are some other potential vulnerabilities, including algorithm rollback attacks, timing attacks, traffic analysis, Bleinchenbacher's attacks, and others. Those interested in understanding them can find more information in Bruce Schneier and David Wagner's document, "Analysis of the SSL 3.0 protocol," (PDF document) as well as in many other documents that can be found on the public Internet. Typical SSL/TLS implementation mistakes
Certificates signed by a CA that is not known to the web browser .:. The biggest mistake that can be made when implementing SSL/TLS is with the signing of the web server's certificate by a CA that is not trusted by web browsers. For example, CAcert.org is not listed in any Mozilla based browser. The CA's certificate is not installed in the web browser and this makes Man-In-The-Middle attacks very easy to perform, because users have no way of verifying the identity of the web server.
To avoid this problem, it is important to make sure that signer's certificate (usually, a trusted CA) is installed in user's web browser. If a local CA was used for signing the web server's certificate, then we must make sure that all web browsers on all clients requiring access have the local CA's certificate installed. The same rule applies to self-signed certificates.
Expired certificates .:. The web browser's certificate should be renewed before the previous one expires. Otherwise it will result in the same problem as above, whereby web clients will not be able to authenticate with the web server -- which once again makes SSL/TLS connections vulnerable to man in the middle attacks. In this case, users may get used to seeing a warning message saying the certificate has expired, and then will probably not notice if it is a bogus certificate.
Vulnerable versions of OpenSSL and Apache .:. It is very important to always run the latest versions of OpenSSL and Apache. Programmers writing larger pieces of code such as these without bugs is virtually impossible, so we should always use the latest stable versions of the above software. The latest versions should theoretically contain fewer security vulnerabilities (both discovered and not-yet discovered) than previous versions.
Acceptance of SSL v2.0, anonymous authentication (aNULL), and cryptography (NULL) by the web server .:. As was previously discussed, the use of cipher suites that support anonymous authentication or require no encryption should be disabled. Otherwise, there is a risk that client can be tricked into negotiating parameters that can dramatically lower the security level of the connection. For this reason we should disable the use of the SSLv2.0 protocol and use TLSv1.0 or SSLv3.0 instead.
Use of weak encryption .:. Early implementations of SSL were only able to use 40-bit keys for symmetric encryption, due to US government restrictions. Unfortunately, the data encrypted by 40-bits symmetric keys can now be decrypted in a relatively short period of time, and for this reason 40-bit and 56-bit keys should no longer be used. Most modern web browsers support 128-bit keys for symmetric encryption, and this is now the minimal recommended length of key for use with SSL/TLS.
Improper use of a Network Intruder Detection System (NIDS) .:. It is important to stress that unless a NIDS is capable of decrypting the SSL traffic (such as through the use of the web server's private key) it is simply unable to detect attacks on the web application. To detect eventual break-ins, we must either use either a HIDS (Host-based Intruder Detection System), or put the NIDS in a segment where SSL/TLS traffic is being sent in clear text, such as between a SSL Reverse Proxy and the web server's farm. Otherwise we may not be able to detect any attacks, except denial of service, performed against the web server.
Allowing access not only via SSL, but also via non-encrypted protocols (HTTP) .:. Setting up SSL/TLS and opening port 443/tcp to the web server, by itself, means nothing if users can still access website via non-encrypted HTTP on port 80/tcp. Thus, one must double-check that the protected content cannot be accessed via non-encrypted HTTP or other protocols (including FTP, Samba, NFS, and so on). It is also important to remember hat is a search BOT like GoogleBot can see the same page in both HTTP and HTTPS then Google might remove the page completely from its index. Only allow a page to be viewed from EITHER HTTPS OR HTTP, never both.
Vulnerable client machines .:. When we focus on securing web servers, we can easily forget about the security of the client machines. If they are compromised, the security of SSL/TLS is compromised as well. In that case, intruders could do as they like with client hosts, such as replace certificates in web browsers, install keyloggers, change /etc/hosts to redirect web requests to bogus web servers, or even steal client certificates if they they have been marked as "exportable."
Therefore, if the client machines are under our administrative domain, we need to take great care with their security. Enabling a personal firewall, antivirus/antispyware software, and turning on automatic Windows updates should be the absolute minimum. Most importantly, web browser versions should be always up-to-date.
It is also recommended that one apply the following options (related to SSL/TLS) to the web browser configuration:
- checking for a publisher's certificate revocation should be enabled
- checking for any server certificate revocation should be enabled
- encrypted server pages should not be stored in the cache
- the use of SSLv2.0 should be disabled, and only TLSv1.0 and SSLv3.0 should remain enabled
- the displaying of warnings about invalid web servers certificates should be enabled
Using the same Session IDs / cookies for SSL and HTTP .:. It is possible to have an Apache configuration that accepts both HTTP and HTTPS requests on the same server, such as an information website accessible via HTTP, and a transaction part accessible via HTTPS. In this case, the we must be very careful in our web application not to use the same session IDs / cookies for both protocols. Otherwise, an intruder can sniff the HTTP traffic between web server and victim, and can try to use session IDs to get access to authorized part of web application via SSL.
Can I use Compression _and_ SSL Encryption together?
Yes, you can. In fact, our pages at Calomel.org are SSL encrypted with AES at 256 bit and gzip'd at level 9 compression. Using compression will allow you to save up to 175% of your bandwith as well as reducing the transfer time of your pages to the client. Both processes take a bit of CPU time, but not enough to load a pentium4 3GHz or AMD64 1GHz server box. Client computers today are fast enough (dual and quad core) to do the decryption and decompression without the users seeing much of a cpu slowdown.
Why does my 2048-bit private key not work?
The private key sizes for SSL must be either 512 or 1024 bits, for compatibility with certain web browsers. A keysize of 1024 bits is recommended because keys larger than 1024 bits are incompatible with some versions of Netscape Navigator and Microsoft Internet Explorer and with other browsers that use RSA's BSAFE cryptography toolkit.
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) are encrypted before they are transferred. So increased HTTPS traffic leads to increased server load.
How do I speak HTTPS manually (command line) for testing purposes?
While you usually use telnet to connect to a normal HTTP server:
$ telnet localhost 80 HEAD / HTTP/1.0for simple testing of Apache via HTTP, it's not so easy for HTTPS because of the SSL protocol between TCP and HTTP. With the help of OpenSSL's s_client command, however, you can do a similar check via HTTPS:
$ openssl s_client -connect localhost:443 -state -debug HEAD / HTTP/1.0Before the actual HTTP response you will receive detailed information about the SSL handshake. For a more general command line client which directly understands both HTTP and HTTPS, can perform GET and POST operations, can use a proxy, supports byte ranges, etc. you should have a look at the nifty cURL tool. Using this, you can check that your webserver is responding correctly to requests via HTTP and HTTPS as follows:
$ curl -I http://localhost/ $ curl -I https://localhost/
Every site I go to says the SSL certificate is expired or invalid!!
Check the system time of your machine. Your browser will compare the expiration date of the SSL certificate with your system's time. If your computer clock is off by, lets say, 4 years in the past then all certificates that are valid for less than 4 years are instantly expired. Make sure your system's time is updated using the network time protocol (ntp).
For example, you may see an error like the following in Firefox if your system clock is slow and the certificate is considered invalid. We got this error by setting the system Firefox ran on to the year 1998.
Secure Connection Failed An error occurred during a connection to calomel.org. The OCSP response is not yet valid (contains a date in the future). (Error code: sec_error_ocsp_future_response) The page you are trying to view can not be shown because the authenticity of the received data could not be verified. * Please contact the web site owners to inform them of this problem.
Questions, comments, or suggestions? Contact Calomel.org