How do peers in WebRTC authenticate each other?
DTLS in WebRTC uses self-signed certificates. RFC 5763 has the details, in a nutshell the certificate fingerprint is matched against the one provided in the a=fingerprint line of the SDP.
As the comment from Patrick Mevzek already mentioned:
It doesn't depend on DTLS or TLS, if a self-signed certificate is trusted/accepted.
This depends only from the peer's trusted certificates. If the client's or server's
certificate path/chain contains a certificate, which signature could be verified by a trusted certificate, then it's assumed to be trusted. There maybe some additional checks as valid time or key-usage or the hostname. The trusted certificates are usually stored in a "trust store".
So, if your server should use such a self-signed certificate, add that self-signed to your client's trust-store. If the client then receives just that self-signed certificate as path, it checks, if the signer (in that case the certificate itself) is in the trust store.
What doesn't work with such self-signed certificates is that other clients, which haven't added that certificate to their trust store, will trust that server.
How do peers in p2p systems like Webrtc authenticate each other?
If these peers add the certificate of the other into their trust store ahead, then they will trust each other.
Do they require a certificate from a CA?
If you can't add the other's certificate ahead, then you need certificates, which are signed by a CA (certificate), which is already in the trust store of the peer's.
Related
I'm confused on how Self-signed certificate works.
Our application will connect to a server to get some info via SSL or https. This mean we are the client. The server is asking us to provide the Self-signed certificate. I created a RSA Key pair and a self-signed certificate.. What cert or key will provide to them? The public key and the self-signed certificate? and do we expect certificate from them?
What cert or key will provide to them?
Only the self-signed certificate should be provided. The private key should be kept private (hence the name).
... and do we expect certificate from them?
This depends if they also use self-signed certificates at their end or if a publicly trusted CA has issued the certificate. In the first case they need to provide the certificate, in the latter case your client just needs to trust the common publicly trusted CA (i.e. what the browsers do).
How do peers in WebRTC authenticate each other?
DTLS in WebRTC uses self-signed certificates. RFC 5763 has the details, in a nutshell the certificate fingerprint is matched against the one provided in the a=fingerprint line of the SDP.
As the comment from Patrick Mevzek already mentioned:
It doesn't depend on DTLS or TLS, if a self-signed certificate is trusted/accepted.
This depends only from the peer's trusted certificates. If the client's or server's
certificate path/chain contains a certificate, which signature could be verified by a trusted certificate, then it's assumed to be trusted. There maybe some additional checks as valid time or key-usage or the hostname. The trusted certificates are usually stored in a "trust store".
So, if your server should use such a self-signed certificate, add that self-signed to your client's trust-store. If the client then receives just that self-signed certificate as path, it checks, if the signer (in that case the certificate itself) is in the trust store.
What doesn't work with such self-signed certificates is that other clients, which haven't added that certificate to their trust store, will trust that server.
How do peers in p2p systems like Webrtc authenticate each other?
If these peers add the certificate of the other into their trust store ahead, then they will trust each other.
Do they require a certificate from a CA?
If you can't add the other's certificate ahead, then you need certificates, which are signed by a CA (certificate), which is already in the trust store of the peer's.
Why does self signed SSL certs throw an unsafe warning? They actually have a smaller attack profile, and not as easily cracked like commercial ssl from a CA. So in reality, a third party cert is more unsafe than a self signed one. Even the wiki page says this: https://en.wikipedia.org/wiki/Self-signed_certificate
A self-signed certificate does not create a security warning if it is configured as trusted in the browser. If it is not known as trusted yet the browser has no way to find out who issued the certificate: it can be the original certificate from the target server or it can be a certificate created by man-in-the-middle attacker. And that's why it is throwing a security warning.
With a CA signed certificate instead the browser can forward the trust it has in the CA (i.e. it is in the local trust store) to the certificates issued by this CA. This means does not need any more to trust every new certificate explicitly up-front but it is enough to trust the specific CA which signed the certificate. This makes the process of rolling out certificates much simpler.
Of course, the risk of the CA model is that one might put too much trust into a CA. The problem of the self-signed model is that you have to find a way to distribute the certificate before connecting to a site in a secure way to the browser - which means that you somehow need to trust this secure distribution of the certificate and that you will run into the same or even worse problems with this than you have in the CA model.
Self-signed carts throw an unsafe warning because your computer does not trust your CA, but (instructions different depending on the environment) you can set your computer to trust your CA.
I'm not sure is similar question has been asked before (I couldn't find any), but is it possible to protect Client/Server from Man-In-The-Middle attack?
I'm writing a Client application to communicate with Server. Communication will be SSLv3 based.
I am OK with server's self-signed certificates, but worried about someone else generating same self-signed certificate in the same server name and pretend to be it. My Client application uses OpenSSL library. [Client and Server are thrift based, if it makes any difference]. Can I avoid such attack at the same time maintaining support for self-signed certificates?
Yes.
In short, a self signed certificate is more insecure than a CA certificate only when the client does not know the certificate in advance and therefore has no way to validate that the server is who it says it is.
If you add the self signed certificate to the client and don't accept any other certificate, you're actually as secure (or, one could argue, even more so) than having a certificate authority signed certificate.
The important parts to keep SSL secure with or without a certificate authority are;
The server private key (and in the case of a CA, the private keys of all its roots) is kept secret.
The client knows the server certificate (or its CA root).
You can hard-code the server's certificate and compare it against what you receive.
Or better yet, create a CA certificate and server certificate, signed by the CA. Have the CA trusted on the client (again by hardcoding it in your application) and validate received server certificate using the CA certificate.
If you can protect your private keys well enough, a middleman will not be able to masquerade as you, assuming the user actually looks at the certificate. The problem with self-signed is that if you want the user to add the exception to their browser, or just ignore the warning, then you are exposed to man-in-the-middle attack, because anyone else may create their own certificate.
Of course, "protecting your private keys well enough" is not trivial at all. When you pay for a "Verisign" certificate, you're not paying for their software creating the certificate - you're paying for the security forces they have guarding the building in which the private keys are stored.
That's easy! NOOOO !!! Not anymore than you could prevent a man-in-the-middle attack from certificate issued-by a well-know authority. >:)
I guess it can't be done, but if so, I'd like to know why.
Let's say I get an SSL certificate for example.com from one of the official certificate authorities around. Let's also say I'm running a.example.com and b.c.d.example.com and would like to have SSL certificates for those as well.
Can I use the example.com certificate to issue certificates for a.example.com and b.c.d.example.com myself? And will they be recognized by users' browsers? If not, why not?
(My guess that it can't be done is because it would break the very lucrative wildcard cert business model, wouldn't it?)
Clarification: can't I act as a "self-signed" certificate authority using the keypair for which I obtained the official cert, and simply add my official cert in the validation chain?
You cannot use Your certificate to issue other certificates, because the purposes of the
certificate are encoded in Your certificate and "Certificate Authority" is certainly not included in that list.
Web browsers check the "certificate chain" beginning from Your certificate, the certificate that was used to sign it, the signer of that certificate etc.
Your certificate must match the current use case (mostly "identify web site") and all signing certificates must include the "Certificate Authority" flag. The last certificate must be known to the browser (root cert).
As You already guess, wildcard certificates might help in Your case.
You're correct, you cannot issue certificates from a certificate. You need a Certificate Authority to issue certificates.
The whole point of a Certificate Authority is that they are a trusted 3rd party. CA's like Verisign are trusted by default by most browsers so that you dont have to manually accept certificates from them. They have what is termed a trusted root certificate.
If you create your own Certificate Authority and start dishing out certificates, web browsers will not know you and hance not trust you. The user will be prompted.