Does SSL require a client side certificate of any kind at all?

Question

A friend insists it does, that both browser and server both need certificates. I say no, only the server requires one, with two keys. The question is whether the browser uses some sort of certificate (not just key) for encryption in SSL/TLS comms with the server.

Solution 1

Your friend is correct. The browser has to have the root certification authority certificate, so that it can verify that the server certificate has been signed by a legitimate certification authority.

Solution 2

The typical case of certificates issued by a trusted party (Let's Encrypt etc)

Server certificates are essential because the client needs to verify that it speaks with the expected server in order to detect man in the middle attacks. To authenticate itself against a client the server needs for this the certificate itself which is public and the private key matching the certificate which is only known to the server. To accept a server provided certificate as trusted the client will then among other things check if this certificate was issued by a trusted party, i.e. a trusted CA (CA meaning certificate authority, i.e. the entity which issues certificates). These trusted CA are stored as certificates in the trust store of the clients operating system or browser. These are the kind of certificates needed on the client side.

And then there are client certificates which are used to authenticate the client against the server. These are optional and used only rarely. If these are used the client not only needs the (public) certificate itself but also the matching secret private key, similar to what the server needs to authenticate itself against the client.

The uncommon case of self-signed server certificates

In this case the server sends a certificate which is not issued by a CA known to the browser (or app or other client). In this case no certificate is involved at the client side but the client needs to find another way to check if the certificate is the expected one. Typically the browser asks the user to add an exception in this case.

The even more uncommon case of no certificates at all

SSL/TLS can also be used without certificates at all, i.e. not even at the server side. In this case authentication is done with other methods, like a secret key pre-shared between client and server (PSK). These methods are rarely used and browsers don't support these.

Solution 3

Let's take a look at what happens between the server and client with SSL. From Wikipedia:

[T]hey negotiate a stateful connection by using a handshaking procedure. [...] During this handshake, the client and server agree on various parameters used to establish the connection's security:

• The handshake begins when a client connects to a TLS-enabled server requesting a secure connection and the client presents a list of supported cipher suites (ciphers and hash functions).
• From this list, the server picks a cipher and hash function that it also supports and notifies the client of the decision.
• The server usually then sends back its identification in the form of a digital certificate. The certificate contains the server name, the trusted certificate authority (CA) that vouches for the authenticity of the certificate, and the server's public encryption key.
• The client confirms the validity of the certificate before proceeding.
• To generate the session keys used for the secure connection, the client either:
  • encrypts a random number with the server's public key and sends the result to the server (which only the server should be able to decrypt with its private key); both parties then use the random number to generate a unique session key for subsequent encryption and decryption of data during the session
  • uses Diffie-Hellman key exchange to securely generate a random and unique session key for encryption and decryption that has the additional property of forward secrecy: if the server's private key is disclosed in future, it cannot be used to decrypt the current session, even if the session is intercepted and recorded by a third party.

This concludes the handshake and begins the secured connection, which is encrypted and decrypted with the session key until the connection closes.

At no point does the server ask the client for a certificate. Usually, in step 4 (confirming the validity of the certificate), the client uses a local store of CA certificates to verify that the certificate chain presented by the server is valid. However, it is entirely possible for the client to use some other method. For example, this is what happens with self-signed certificates: your browser will ask you if you want to accept this certificate which cannot be verified, and if you confirm, it happily goes on to finish the handshake. Command-line clients like curl and wget have options to indicate that you don't want to verify the certificate chain.

The client does not need to have certificates, but it's good practice to verify who the server says they are, and that means the client needs CA certificates to verify the certificate chain presented by the server.

It is possible to configure the server to ask for a client authentication certificate. See this MSDN post for an illustration.

Comments

[Steffen Ullrich]

Given that the answers here differ a lot in technical detail and context (i.e. usual browser behavior or not) I recommend to ask at security.stackexchange.com if you want to get a better picture of the problem. In short: in the common case most care about certificates are needed at the client. But there are cases were no certificates are needed at the client. And there are even cases where no certificates are needed at the server.

[richp]

This is a very ambiguous question. Are you asking whether the browser needs a copy of some certificate (e.g., a trusted CA root), or whether it owns its own certificate (client identification sent to the server)?

[Jörg W Mittag]

I don't even own a client certificate, yet, I can seem to browse SO, which uses SSL perfectly. This shows that we don't need a client certificate.

[Steffen Ullrich]

@JörgWMittag: The question does not specifically asks about client certificates but about client side certificates, i.e. certificates needed on the client side. And this answer correctly says that certificates are needed at the client side: the CA certificates which are used as trust anchor. And since these CA certificates already come with your OS and/or browser it works for you without installing additional certificates. Thus, the answer here is not wrong, it is only not that detailed.

[muru]

@SteffenUllrich SSL works fine with self-signed certificates on the server side, which don't need any CA certs on the clients. This answer is wrong.

[Mike Scott]

@muru No, it only works fine with self-signed CA certificates if you install your own root CA certificate in the browser. Otherwise it encrypts but does not authenticate the server, which is not “working fine”; it’s a massive security risk.

[muru]

@MikeScott And I suppose curl installs this root certificate somewhere as well?

[Mike Scott]

@muru Curl requires a root certificate bundle for SSL, yes. See here: curl.haxx.se/docs/sslcerts.html

[muru]

@MikeScott Not with -k it doesn't. That's literally the first point of the "Certificate Verification" steps.

[muru]

@MikeScott that is insecure, but that does not prevent curl from setting up the SSL tunnel with the certificate given. There is a reason why it exists: because SSL does not need verification. (It's good practice to verify who you're talking to, of course, but that does not mean it's necessary.)

[Mike Scott]

It depends on your definition of "require". Root CA certificates are needed on the client side to establish secure and non-interceptible connections, which is what most people would expect to get from SSL. You can use part of the SSL protocol to get encrypted but insecure connections, but that's not really using SSL for its intended purpose.

[muru]

@MikeScott encryption without authentication can be meaningless, yes, but that again depends on the use-case. For example, the vast majority of people who use SSH (not to be conflated with SSL) never actually verify the server's fingerprint. And arguably that's also not using SSH for it's intended purpose. "Intended purpose" is a mostly meaningless term when it comes to what happens in reality, and what happens in reality is that plenty of people also use SSL without verifying the presented certificates.

[Steffen Ullrich]

@muru: In theory you could use SSL/TLS without any certificates on any side, i.e. with no authentication or certificate-less authentication like SRP or PSK. You could also use a certificate on the server side and just check the fingerprint on the client side. But, for practically all cases which are relevant for web masters you need a CA on the client side to check the server certificate. For the finer details I recommend to discuss these at security.stackexchange.com since this is the more appropriate forum when discussing TLS security outside the common browser case.

[Steffen Ullrich]

I think the main problem here is that there is SSL/TLS as most use it (with CA issued certificates) and SSL/TLS how it can be used too (self-signed w/o CA, no server certificates at all with SRP, PSK or None authentication method). And different answers here address different views of SSL: the commonly used case vs. the uncommon but technical also correct case.

[muru]

@SteffenUllrich indeed, yes. The question seems to be for settling an argument, so it depends on whether OP's friend will settle for technically correct vs best practice.

[CodesInChaos]

Having a list of trust anchors on the client is completely different from using client certificates.

[Mike Scott]

@CodesInChaos Yes, but the question was about certificates "of any kind at all", not just certificates to authenticate the client, and CA root certificates are a kind of certificate in the browser.

[BlueRaja - Danny Pflughoeft]

-1 I read the question as "do both the client and server need certificates which belong to them?" to which the answer is "no". This answer says "the client needs to know about the CA's certificates", which is correct but, I believe, misinterpreting the question.

[Sean Burton]

A lot of people mistakenly say 'certificate' when they mean 'private key', I expect that when the question talks about the client having its own certificate it means it having its own private key to use for client-auth, rather than just having a CA certificate in its store, though without clarification from the original poster we can't really know what they meant...

[user]

@muru Lots and lots of SMTP STARTTLS is encrypted but unauthenticated, and that's fine. For lots of (but not all) threat models, even unauthenticated, best-effort, opportunistic encryption beats the living daylights out of transferring data in plain text, because it hugely reduces the value of passive eavesdropping. Sure, in a technical sense, an attacker can just prevent the opportunistic upgrade to TLS, but that forces the attacker to become active. Lots of attackers are unwilling or even unable to be active.

[user]

I could go into more detail, but I already ran out of space in the margin once, so I'll just suggest you go and read Internet Best Current Practice 188, also published as RFC 7258, on how Pervasive Monitoring Is an Attack which "should be mitigated in the design of IETF protocols, where possible". Do note that monitoring, even pervasive monitoring as done by many nation-state actors, is not the same thing as actively attacking either infrastructure or endpoints; the two are sometimes related, but not identical.

[ProfK]

@SeanBurton The assertion this question is based on was about certificates, not just keys.

[Sean Burton]

@ProfK in that case, what everyone's saying is correct, the client doesn't need it's own private key and corresponding certificate but it does need a trusted CA certificate in its store to be able to verify the server's certificate