SSL, TLS, and protocols-over-them notes

From Helpful
(Redirected from SSL and HTTPS notes)
Jump to: navigation, search


This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

Approximate introduction

what it does

SSL/TLS are enough to set up encryption on a connection, securely in at least a 'someone snooping on traffic flowing by won't get anything useful' sense.

And for that to have much point, you need a mechanism to be sure who the other side is, which ends up being the other big thing it's useful for.

The latter is why all the certificate stuff is involved, and chains of vouching for each other. (Basically that's more practical, for a large number of endpoints, than direct pre-shared knowledge.)

SSL versus TLS

Transport Layer Security (TLS) is standardized by IETF.

It has succeeded Secure Sockets Layer (SSL), designed by Netscape.

Most current systems implement both, though because of various recent exploits, most of SSL and half of TLS is now considered flawed and typically disabled (so that it won't be negotiated. Best and usually done at the server side).


Given that:

  • SSL/TLS clients have a set of trusted certificates, usually stored in and managed by the OS, though a client can add its own store (and e.g. some browsers do).
  • Certificate authority A can effectively assert they trust party B, vouching for all certificates that B signs.
    • clients given a certificate B can verify that this could only have come via A

This means that if a client already trusts A, it is verifiable that (a certificate from) A is the origin of (a certificate from) B, then (that certificate from) B is trusted.

The certificate for any particular website you visit can be a few steps down from a major known-and-trusted authority. Same idea, slightly more time spent setting up a connection.


Certificate profiles refer to conventions of expecting what appears in a profile.

This was basically required to make X.509 practical, as X.509 itself is somewhat open-ended, and its varied use initially got messy.

That meant there is a fairly small set of features you can count on unless you want to tie yourself to a particular implementation/profile/locale.


Certificates as files

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

Servers using SSL will usually refer to two separate entities, the certificate and the private key. It should be noted that people seem to use 'certificate' can refer to the whole shebang, or to just the public part of it.

In more detail:

  • The private key, which will stay at the server side and must remain secret. Always necessary.
  • The certificate, which acts as a public key, because the server must first send it to the client for anything useful to happen at all.
    • Such a certificate is often signed by a third party that the client already trusts, so that the client can verify this certificate
    • Once verified, you could set up encryption, and browsers often do
    • Some programs don't do that, they just want to make sure they're talking to specific trusted server
    • a chain file refers to a file containing more than one certificate. Nothing special SSL-wise, the chain must be still be verified by the client. The point is often that the situation requires more than one step to get to an already client-trusted point. Consider for example a CA that has trusted a university to sign its own certificates).

CAs (and other signers) deliver certificates to its clients a set of files, in one of a few formats.

A SSL-capable server may only take one, so sometimes you need to convert between these formats (or ask the CA for it in the other format).

Files that contain certificates/keys often have extensions either to indicate their file coding or what sort of thing they contain.

Type extensions include:

  • .csr: certificate signing request
  • .key: private key
  • .crt: certificate

Format extensions include:

  • .pem, (sometimes .b64): PEM, a Base64-like format used by a few common services, so often containing either a certificate or a private key. (PEM was initially created for Privacy Enhanced Mail)
  • .p12, .pfx: PKCS#12, may contain certificates and private keys (password protected)
  • .p7c, p7b: PKCS#7 SignedData structure without data, just certificate(s) or CRL(s)
  • .der (ASN.1 DER)
  • .cer (ASN.1 CER)

CA-signed certificates versus self-signed certificates

For real-world use like "I want the little lock thing in my browser to green to know I can trust it", you usually ask a Certificate Authority (CA), which decides to sign it (or not), after which the resulting certificate is chained to that CA, and SSL clients can verify that link in the chain of trust, i.e. that that specific CA signed it.


  • Verification is not necessarily authentication:
    • very sloppy CAs may issue more than one certificate for the same site, to a different person, which would mean more than one person can host a site verified in the sense above.
    • ...unless you knew which specific certificate to expect.
  • this and other trust issues creates an oligopolous market for (trustable) certificates. As such, stronger certificates are pricier.

Self-signed certificates

An alternative is self-signed certificate, which can be generated independently. These are not chained to something a client will already trust.

A client will say it can't be verified, and/or ask the user whether they want to trust this particular certificate.

Given that you don't mind the initial warning, and that you can verify the certificate yourself, then it still lets you authenticate the server, and can give you a securely encrypted connection.

If you blindly accept any certificate, then you open yourself up to man in the middle attacks. For this reason, web browsers have recently added a copious amount of warnings and roadblocks so that people can't just blindly trust arbitrary certificates.

Note also that bundling a certificate with your software (so that its SSL client already has the certificate) can also go a long way towards security without bothering users (but be well-informed when you do that).

A self-signed certificate can also useful to experiment with SSL, and to test a setup (and its SSL config) before requesting a certificate.

I've also used one to avoid sending plain-text passwords to some of my own servers. It means installing the certificate on each client I want to (verifiedly) trust it, though.

SSL client libraries can often be configured to skip certificate verification, which is interesting in cases like -->


HTTPS is plain old HTTP that happens to be transferred over a connection that uses TLS/SSL.

Most browsers and servers implement this combination fairly transparently.

By default, https:// URLs imply use of port 443. It's up to the server whether it also still serves unsecured content on port 80, but there is usually at least something there (if only a redirect to https).

See also:

Uses: Login (and more)

Systems that use HTTPS sometimes use it only for login. This avoids plain-text passwords on login, and avoids any possible latency (and server encryption load) on the rest of the website, which is typically much less security-sensitive.

While this works against password snooping, it does not protect against other things, such as session hijacking by people snooping on the same network. See e.g. Firesheep.



For apache config details, see Apache config and .htaccess - security


Browsers and certificates

Firefox uses its own store, and ignore the windows one (all OSes or not?).

It seems that FF wants to know the difference between officially provided certificates and those added by OSvendors/sysadmins/users, so that it can choose to accept only the former. MS does not make that distinction.

As such, you'll have to add it yourself. Enterprise packagers are less lucky, though.

See also

For apache (also containing general answers)