SSL, TLS, and protocols-over-them notes

From Helpful
Jump to: navigation, search
Security related stuff.


Theory / unsorted

how to do a login system badly
how to do encryption badly
encrypted connections
data-at-rest encryption


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, or tell me)

What it does

SSL/TLS is a bunch of things.

Most important are probably the abilities to:

  • Set up a connection that no one (that doesn't know very specific secrets of the endpoints) will be able to snoop on
even if they have down-to-the-wire control of the network
  • Be able to
authenticate who a specific endpoint they are based on pre-existing trust OR
that they are vouched for via pre-existing trust

There are a slew of footnotes to this, primarily because of how that trust works - and mostly for practical, not technical reasons.

For one, the identity part is necessary for the encryption to mean anything. Say, if you are not talking to the person you think you are talking to, and cannot tell, then that connection being secure is not the point.

Note that the 'specific endpoint trust' may be stronger, but on the internet, where almost all hosts you connect to are ones you've never talked to before, that vouching-for system is a lot easier (than trying to manage millions of individual trusts), but both of those would come with their own footnotes that are best not forgotten.

What it only usually does / only sometimes does / never does

What's all this with certificates


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 the first time.


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, 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 carried through a TLS/SSL connection. Most browsers and servers implement this combination 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, now, often just a redirect to https).

See also:

Is it slow?

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, or tell me)

Slow here refers to two questions:


"Does it take extra time to set up?"


On a new connection, there are roughly three or four round-trips that TLS typically needs to do.

3*RTT before any user data can flow.

...which is more than 1*RTT of unencrypted connections.

RTT to a server is unlikely to ever be less than 15ms, and on mobile or across an ocean that's maybe 100ms. Three or four times that means we now need to wait 60 to 400ms. The low end is fine, the latter less so.

There are further details, like that checking certificate revocation adds time - which can be alleviated with OCSP stapling.(verify)

That said...

"Does it take extra time once set up?"


Basically, TLS + some sort of keepalive / pipelining (and considering session resumption) means you incur that setup cost once, but very little on later exchanges over the same connection.

In earlier HTTPS, order mattered more (head of line blocking and all that).

Since HTTP/2 multiplexes to a host, you incur it a lot less for multiple requests to a host even when one request blocks. But it's not widespread yet.

(also it doesn't apply equally well to all mobile)


dozens of kilobytes to maybe more, which can be a real issue on microcontrollers, but peanuts to everything larger.

Uses: Login (and more)

Systems sometimes use HTTPS 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.

Is in necessary?



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



Can you proxy TLS?

TLS on embedded platforms

Browsers and certificates


Adding server certificates:

Preferences →  Privacy and Security → Certificates → View 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 may choose to accept only the former. e.g. Windows does not make that distinction.

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


Adding server (or client) certificates:

Chrome Settings →  Show advanced settings →  HTTPS/SSL →  Manage Certificates

May complain even on correctly installed certificates, if it uses what it considers net::ERR_CERT_WEAK_SIGNATURE_ALGORITHM

See also

For apache (also containing general answers)