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.
2
-
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.– Steffen UllrichOct 12, 2017 at 10:49
-
4This 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)?– chrylis -cautiouslyoptimistic-Oct 12, 2017 at 23:36
Add a comment
|
4 Answers
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.
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.
-
5@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. Oct 12, 2017 at 8:01
-
5@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. Oct 12, 2017 at 9:30
-
2@muru Curl requires a root certificate bundle for SSL, yes. See here: curl.haxx.se/docs/sslcerts.html Oct 12, 2017 at 9:39
-
2@muru Yes, but the "-k" option tells curl not to work properly. There's a reason why it's also called
--insecure. It will encrypt but not authenticate, and that's not secure. Oct 12, 2017 at 9:41 -
3@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. Oct 12, 2017 at 10:23
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.
-
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. Oct 12, 2017 at 9:47
-
@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.– muruOct 12, 2017 at 9:53
-
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. Oct 12, 2017 at 10:54
-
@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.– muruOct 12, 2017 at 10:57
-
1@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.– userOct 12, 2017 at 21:56
TLS can work without any "TLS" certificate (that it truely a X.509 certificate in fact), this is orthogonal. One endpoint can have a certificate, or both, or none at all. TLS provide different benefits, authentication is only one of them (but the most important one in fact, over confidentiality which is often counterintuitive)
answered Oct 14, 2017 at 15:42
