Public key encryption; SSL and TLS

From Helpful
(Redirected from SSL and HTTPS notes)
Jump to navigation Jump to search
This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)
Security related stuff.


Linux - PAM notes · SELinux

Securing services


A little more practical


More techincal waffling

Message signing notes · Hashing notes ·
Auth - identity and auth notes
Encryption - Encryption notes · public key encryption notes · data-at-rest encryption ·pre-boot authentication · encrypted connections

Unsorted - · Anonymization notes · website security notes · integrated security hardware · Glossary · unsorted

Public key encryption notes

What public-private keypair is/does, at a basic level

What it consists of

Public key encryption is named for its asymmetric key scheme:

  • keys are generated and exist in pairs: a public one, and a private one
    • everyone should be able to get hold of anyone's public keys (hence the name)
    • no one but you should ever have your private key
  • it is nearly impossible to derive the private key from the public key


Notes:

  • be careful when storing private keys on public/networked systems.
    • It is technically better to carry it around on a usb stick or the likes.
    • ...but in some uses, the private key has to be out there.
      • Yes, that is an issue
      • Yes, there are ways to deal with that.


The two basic things you can do with it

Such a keypair generally lets you do two things:


Encrypting

Sometimes you want to ensure that only a specific group of people can read your message at all.


Using the other side's public key, you encode a message to something that is now unreadable

and only the the according side's private key, which only they have, can be used to read it out again.
but no one else can decrypt it


A specific pair of keys can set up a single encryped connection, unrelated to any other connection.

Note: 'connection' can mean both

individual messages, as in secure email packing encrypted messages within an unsecured transport
a transient network connection, as in SSL / TLS


Actually, SSL / TLS is more complex. Not so much for technical reasons, and more for practical reasons: how do you set up many distinctly secured connections without a mess of keys?

Turns out they thought of that, but it's a separate topic for that reason. We get into that later.


An analogy (for encrypting only) is that

a person hands out open padlocks (their public key) that anyone can close on a box with a message
and only the person with the padlock's key (the private key) can open it.

(The analogy breaks down quickly. Unlike most physical cylinders, no you can't take it apart to just read off the pins. Reverse engineering a private key from a public key is intended to be intractably hard. This analogy is also completely backwards for the other thing you can do, signing:)

Signing

Sometimes you want to ensure only that only a single person can have written the message, but not hide that message.

That is,

you do not need any key at all if you choose to just trust things blindly,
checking it is an option you have.


Using your own private key, you adds a signature data to an otherwise-readable message.

anyone else can verify that signature with the public key that you gave out publicly
but no one else can imitate that signature


Anyone can use the public key, to verify that that signature could only have been generated with the according private key.

'Using your public key, other people can decode and thereby verify a message was signed by you/your private key. (...by the same identity: each identity has an inseperable private key and public key).


Notes:

  • In both cases, a private key is kept secret
The difference lies in part in the mechanics of where it gets kept, and how it gets used.
  • In both cases, note that none of this is meaningful if you cannot verify that the public key actually belongs to the party you had in mind
if you don't verify that, out of band, you are allowing yourself to be man in the middle'd

What it doesn't do by itself

Without verifying identity, it's easy to do meaningless encryption

That is, you can always use someone's public key to encrypt data so that only they can read it,

...but if you never checked it was their public key, well...


Put another way, if you are not talking to the person you think you are talking to, that connection may be perfectly secure -- against the wrong person

if you cannot verify, then the service is fairly meaningless
if you can verify, but don't, then you are fooling yourself. This is what we might call LARP security.


Put in terms of some consequences:

If I come in tomorrow and stick an extra wire into your network, can I read out anything? No, probably nothing.
If I were always impersonating the remote party, can I read anything off? Yes, in fact basically everything.



Consider the situation where you though You were talking to a Server:

Y---S

BUT from day one, all communication was actually from You to HackerMe, and from HackerMeto the server:

Y--H; H--S

We now have two separate pieces of communication, which are perfectly encrypted in that "apart from these three parties, no one can listen in."

The problem is that you probably wanted that sentence to read "Apart from these two parties, no one can listen in."


(This actually isn't the most likely threat, for the practical reason that unless I am in the middle of all your communication from now on, you will find out quickly. Unless I am part of your infrastructure, I won't manage to do that.)


There are ways to check that.

But doing in a fully automated way can be weaker than you would think, so the best way is to verify it yourself.


Unsurprisingly, people have figured out a balance, where it is moderately easy to check while not being too much of a bother.

Several, in fact.

Verifying once: Key fingerprints

In the end, the largest weakness is probably making sure keys actually belong to the someone you think you're talking to.

Key fingerprints are a way to do that.

Note that 'fingerprint' here only means "we can be damn sure it's the same key while reading off something shorter than reading off the entire damn thing". Usually just a hash of that key data.



Consider that to prevent a man-in-the-middle attack, you need to

  • compare keys before you can safely use them
  • not verify it over the same channel you are going to communicate over -- if you could trust it, you probably wouldn't need to do this in the first place


On a practical note

For personal use where you just use encryption so that your messages aren't easily snooped from the physical network, this isn't so pressing.


And the man-in-the-middle attack usually isn't a worry for most of the general public, in the sense that someone either has to have interest in man-in-the-middling you specifically at this point in time already (If they want to do so after keys are verified, well, they can't), or has somehow automated this (but that's hard to do unnoticed).


That said, persons of interest may have automatic attacks targeted at them, and very much care about doing this right.


Checking fingerprint consistency

SSL, TLS

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, 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:

  • to set up a connection that no one (that doesn't know very specific secrets of the endpoints) will be able to snoop on - encryption
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
via certificates - more on the strengths and weaknesses of this later


  • be able to delegate that trust -- by saying they are vouching for something else
...also via certificates - again, more on the strengths and weaknesses later
while the previously mentioned certificate-explicitly-naming-an-endpoint is a stronger statement,
the internet is made of too many host you can't all mention, and which you've never talked to before, so this vouching-for system is a lot easier
that said, both these alternatives come with plenty of footnotes that are best not forgotten.



At the core, it uses public-private keypair to do a bunch of that, but in the end, that only helps answer "can we trust its implementation is solid" (basically yes), not "are there ways to break this regardless", because the slew of footnotes mostly comes from how that trust works and mostly for practical, not technical reasons.


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

What's with certificates? What's this about chains?

The starts of trust chains

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.


Signing

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.


Root certificates

Intermediate certificates

Who trusts the trusters? or, how to break this system

Can organisations intentionally man-in-the-middle their users? Can this be sensible?

Someone is asking me to install a certificate. Should I do this?

Unsorted

Things change - OCSP and CRL

Verifying

Certificates as files

This article/section is a stub — probably a pile of half-sorted notes and is probably a first version, 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.


Notes:

  • 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.


http://www.akadia.com/services/ssh_test_certificate.html


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


HTTPS

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 and is probably a first version, is not well-checked, so may have incorrect bits. (Feel free to ignore, or tell me)

Slow here refers to two questions:


Time

"Does it take extra time to set up?"

Yes.

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, instead of 20 to 150ms.

The low end isn't noticeable, the higher end is.


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


That said...


"Does it take extra time once set up?"

Little.

If you add some sort of keepalive and/or pipelining, or consider session resumption, it means that you can incur that setup cost once, and much less on later exchanges over the same connection.

In other words, you you get it once per X amount of time on a specific server.


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)




Memory

dozens of kilobytes to maybe more, which can be a real issue on microcontrollers (HTTPS on an ESP8266 is barely possible), 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 it necessary?

HSTS

HSTS (HTTP Strict Transport Security) lets a site declare that requests to it should never switch from HTTPS to HTTP.

This mainly protects from downgrade attacks on domains that serve both secure and unsecure content.


It mainly amounts to a single header, Strict-Transport-Security.

See e.g. a description here, or perhaps the specs in RFC 6797.


Notes:

  • You can guard from downgrade happening accidentally by configuring your server to not serve most of the site on HTTP, and to unconditionally redirect HTTP to HTTPS on the secure part
this is quite decent, but not full protection against downgrade attacks, in that if you allow the initial connection to be HTTP (even if purely to redirect to HTTPS), that part is still vulnerable to a man in the middle attack to redirect you elsewhere.
  • when introduced, HSTS was correlated with certificate errors
...because a bunch of hosts didn't have their config quite in order, and the browser could no longer opt to go to HTTP
and this was introduced well before the time that browsers started defaulted to HTTPS over HTTP (verify)
  • "HSTS preload list" is a list of sites that request to only ever be queried securely
browsers can load / hardcode these, you may be able to add your own
note that this only makes sense when all content is served over HTTPS (and HTTP is only used to redirect).
There are some other practical restrictions
includeSubDomains is relatively obvious
preload is part of becoming part of a preload list. Not part of the spec (a google thing) but most follow it.
max-age is how long a browser should remember this HTTPS-only fact. preload list require this to be at least a year, preferably two, presumably to show commitment to this concept
https://hstspreload.org/

Testing

Apache

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

Notes

SNI

Can you proxy TLS?

TLS on embedded platforms

Browsers and certificates

Firefox

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.



Chrome

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)