Exploring HTTPS

Nobody will bother to hand you an introduction to HTTPS/SSL. Casual netizens recognize the green lock by the address bar well enough, but deeper technical knowledge can be inaccessible to programmers who are accustomed to a simple HTTP/1.1 transaction.

Here’s what I’ve learned exploring HTTPS:

• Welcome. There, I said it.
• HTTP and it’s cousin HTTPS are just two of many communication protocols that are the application layer protocols.
• A protocol is nothing scary, just a set of rules. Other communication protocols include FTP, SMTP, OSCAR (for AIM), IRC, and Morse Code. They determine how two computer should exchange information with each other. A large part of this communication is actually in plain English.
• Protocols are written in essay-format and are publicly available for anybody to read. They are written by one of the many organizations that are responsible for writing protocols: the W3 and the IETF being major ones.
• The application layer is one step above the transport layer in what’s called the OSI model of computer networking. At the very basic level, computers communicate through signals in integrated circuits and wiring. As you move up the tiers, processes appear to become more simple, but their inner workings grow more and more complex. A simple command like email a file involves a terribly large number of actions from encoding attachments to base64 to packaging the message using the SMTP protocol.
• HTTPS is actually HTTP, an application layer protocol, wrapped inside SSL/TLS, a transport layer protocol.
• People use HTTPS for (1) authentication, ensuring that you’re talking to who you think you’re talking to, and (2) encryption, preventing a middle man from intercepting and reading what you’re saying.
• Encryption, the easier of the two, occurs after the two parties decide on a shared private key without the possibility of a third party knowing the key. The process of exchanging keys is actually very simple. See Diffie—Hellman key exchange – Wikipedia. Thereafter, only the two end parties can understand what’s being said.
• Authentication is more difficult because it’s impossible to have a digital fingerprint of every single website on the Internet that you might want to securely connect to. For this reason, you generally have no way of knowing if a middle man is intercepting, reading, and modifying every communication between you and a website in order to get you to reveal sensitive information.
• Web browsers have solved this issue by shipping a small number of digital fingerprints included in every web browser, more formally called the public keys (fingerprints) of Certificate Authorities (CA’s).
• Public keys are so named because they are public, and for everyone to see, use, and have. Private keys, their counterpart, are highly secure and are held only by a certain person or organization. In short, public keys can be derived from private keys, but not the other way around, like a signature can be derived from muscle memory, but one cannot easily learn to forge a signature. See Public-key infrastructure – Wikipedia.
• In turn, the Certificate Authorities verify the identity of each website and sign what’s called the SSL Certificate of a website. These certificates then have both the identity of the website and the identity of the Certificate Authority embedded in them.
• You may not be able to verify the identity of a website, but you certainly can verify the identity of a CA using the public key that you already have.
• For a website owner, you can get your website’s identity verified by a CA. Sometimes, they are free, and other times, they come at a yearly fee.
• All versions of Internet Explorer on Windows XP require that you have a dedicated IP address for each domain for which you want HTTPS enabled. Beware.
• Extended verification is a higher degree of authentication available to website owners who are more concerned that visitors can be certain of who they are. Web browsers usually show the name of the organization next to the address bar. See Bank of America for an example.
• All of this security can be undermined if someone installs a malicious CA fingerprint into your web browser without your knowing. This is common practice in many schools and organizations where the authorities value their ability to see what you’re doing over your privacy and security. Beware.
• HTTPS Encryption is supposed to occur before the HTTP request is exchanged, so even the URL should not be visible to a middle man.
• SSL/TLS prevents caching of pages because each visitor will have a different key associated. Feeding pages through HTTPS requires more CPU time and memory, so don’t use it when it’s unnecessary.
• CA-granted certificates expire. Remember to renew them before it’s too late.
• StartSSL offers basic SSL certificates for free.
• All this is much easier to set up when you have access to your entire server’s configuration (as in a virtual private server or a dedicated machine).
• Don’t try to create your own key exchange algorithm using JavaScript and server-sided logic. Remember, your JavaScript isn’t worth beans if it can be tampered with in-transit.
• If a client (or you) is getting SSL errors on every website, check the system clock. If the clock is wrong, every certificate will appear to be expired.
• Resources, like images and scripts, on a HTTPS website also should be transferred through HTTPS. Some browsers will throw a fit if they aren’t.
• Instead of changing all your http:// to https:// or vice versa, use protocol-relative URLs. The following is supported on all modern web browsers and is almost-fully supported on IE7/IE8:

<img src="//rogerhub.com/logo.png" />

• Certificate Authorities are not infallible. They have been compromised and used to spy on people in the past. See DigiNotar SSL Revocation.
• A form on a normal HTTP page can be specified to submit to a HTTPS page. The form data will be encrypted, but this is still an unsafe practice because the form itself may be modified in-transit.
• The existence of HTTPS does not make HTTP any less secure. In reality, HTTP was never secure in the first place. The standard HTTP protocol was not meant to have any security features attached to it, and anything transmitted through it should be considered insecure and tamper-prone.
• It’s best practice to specify a chain certificate in your HTTPS server configuration. Sometimes, a website SSL Certificate is signed by a intermediate certificate which is then signed by the CA. Providing this intermediate certificate is required by some browsers, but not by all.
• A CA’s top-dog certificate, the one that it uses to sign everything, intermediate certificates and all, is known as its root certificate.
• Your web server needs both the SSL Certificate (which is provided to the visitor) and the SSL Key (which is private) to operate. Don’t forget the latter.
• Make sure your web server’s file permissions are configured to prevent anybody else from reading your SSL Key. It must not be compromised, or anybody can impersonate your website.

Security is not a state, but an active game. Make sure you watch computer security news media and keep up with security bulletins if you are responsible for computer security. Good luck.