For webrtc peers, what domain is dtls used for negotiation? I am puzzled. There seems to be no relevant attribute definition in the sdp. Is it the domain where the web page is located?
WebRTC doesn't use a certificate authority. No domains are involved. With WebRTC the Authenticity that you get from PKI is just replaced with certificate fingerprints.
Each side generates a certificate and then shares the fingerprint in the Session Description (Offer/Answer). After the DTLS handshake is complete it makes sure that the certificate exchanged was the same.
How DTLS actually works is explained in WebRTC for the Curious#Securing a bit more.
Related
Sorry I'm not a cyber security expert but I'm looking for some insight! I would like to encrypt a standard TCP socket communication and thought about using SSL. Both devices might not be connected to the Internet and cannot communicate with a root CA to validate their certificates. This should do the trick to prevent sniffing the communication but doesn't protect agains man in the middle attack.
Alternatively, devices could generate and sign each other certificates but how to make this procedure secure?
Since it's pretty easy to hack, it probably doesn't worth the effort to implment ... Right? Or what encryption mechanism would you recommend?
Both devices might not be connected to the Internet and cannot communicate with a root CA to validate their certificates. This should do the trick to prevent sniffing the communication but doesn't protect agains man in the middle attack.
Not true. If a device is unable to reach internet, it would be unable to check certificate revocation (CRL/OCSP) . The client would still be able to validate the other's party certificate and its validity.
Alternatively, devices could generate and sign each other certificates but how to make this procedure secure?
You don't really need to sign each other's certificate, the parties just need to trust them.
As already commented, you can use a self-signed CA or a self-signed certificate and then there's a question how do you protect the generated and CA private keys (isn't that always the case?). IMHO - even without any internet access using the qualified certificates (signed by a trusted CA) is a good /best option.
pretty easy to hack.. Or what encryption mechanism would you recommend?
No, not really "easy to hack" provided you keep the private keys private.
I'd say SSL is the best option for ensuring confidentiality and integrity of the transport channels.
For the purposes of secrecy and authenticity of communications I use SSL / TLS (https) with client certificate. If I log the entire SSL traffic on the server side, is the SSL log sufficient evidence that the communication between the server and the other side with client certificate was exactly as it is recorded in the log? At the beginning an asymmetric handshake is used but further communication continues with symmetric encryption. Symmetric encryption would not mind if one of the messages cannot be forged on the receiving side. As a server I know the symmetric key so it should be able for me to spoof one of the messages sent by the client, shouldn't it? What algorithm and what special settings shall I use, so that client could not say that he sent a different message than what I recorded in the log?
Logging anything (including data from SSL) does not proof the origin of the data. In theory you've could made up the data yourself. Even logging the complete SSL traffic including the necessary encryption key does not proof anything because in most cases this could have been made up too.
It might be acceptable as a proof if the whole SSL traffic is logged including the encryption key and if a client certificate was used for authentication (i.e. two-way SSL). The real client certificate owned by the client is a part you can not make up yourself. But there is still no guarantee that some judge would accept it as proof. And of course the client could try to deny that this is its own client certificate which was used.
I am working on a product that would be http POSTing some data to my server everyday. The server doesn't send any data/REQUESTS to my device (other than the HTTP status). I use a redpine wireless module RS9113 that does the connectivity piece for me. I want this communication to be https enabled and my web server already has a CA-issued certificate.
Question is :
When I do a POST from my embedded device, my understanding is that the SSL library would check the validity of the server certificate. Am I right ?
If my client doesnt need a certificate, does it mean the public key of the server is stored on the wireless module (and this is used for encryption everytime) ? I can guess that this is something I need to ask the redpine wireless folks, but can you give me a general idea how this works ?
In this setup, do I need to have any certificate ON my embedded device ? I am ok if anybody POSTs the data to the server because we have identifiers that would flush out the non-conforming structure of data. If there is no cert on the device and if we POST, does it mean that the data is encrypted from device-server ?
Bonus question : In this setup, if my cert on the server is renewed, will it cause any problems in sending the data ?
I do not know the redpine wireless module, so take this response as a resolution of doubts about SSL in general
When I do a POST from my embedded device, my understanding is that the SSL library would check the validity of the server certificate. Am I right ?
Yes, the SSL library should check that the issuer of the certificate (the root CA) or the certificate itself are present in the trust store. If you use a self-signed certificate or a CA that is not present in the truststore, you have to include the public key in the truststore
If my client doesnt need a certificate, does it mean the public key of the server is stored on the wireless module (and this is used for encryption everytime) ?
The two things are not related. You need the public key of the server in the wireless module to establish trust. A client certificate would be needed if you use two-ways authentication. The client certificate is presented during SSL handshake to authenticate the client to the server
In this setup, do I need to have any certificate ON my embedded device ?
No, if two ways authentication are not required
If there is no cert on the device and if we POST, does it mean that the data is encrypted from device-server ?
The client certificate, if any, is not used to encrypt. Is used to authenticate during the initial handshake. The handshake stablish a symmetric key used to encrypt and decrypt the communication in both sides.
In this setup, if my cert on the server is renewed, will it cause any problems in sending the data ?
Depending on the setup of the server certificate on your client truststore. If the new certificate is issued on the same side, it is enough to have imported the root CA. If you use self-signed certificate, you will need to import the new one
I'm using ADAL(a 3rd party OAuth2.0 implementation). I'm trying to collect traces of the communication using Charles as a proxy.
What I imagine is happening (not relying on anything):
ADAL requests a certificate from the Authority through Charles
Charles requests a certificate from the Authority and passes it to ADAL.
ADAL wants to open an SSL channel with the Authority but actually opens it with Charles.
Charles opens an SSL channel with the Authority and forwards any requests/responses to ADAL
However, ADAL rejects the Authority's certificate.
Now as far as I know, certificates are passed unencrypted. So if I was correct in describing all the above steps, how does ADAL know that the entity he's talking to isn't infact the Authority he's supposed to be talking with?
ADAL doesn't really look at the authority's certificate - it checks that the channel used to connect to it is trusted. The presence of a proxy can disrupt the SSL channel trust. If I want to connect via SSL to www.domain.com, I expect the certificate used to establish the channel to be in my trusted authorities, to have a subject that contains www.domain.com, to be still within its validity period, and so on. I am not familiar with Charles, but I guess it might look like a DNS redirect attack from ADAL's viewpoint. You can turn off authority validation in the constructor of AuthenticationContext if you need to do a quick test, but I would strongly recommend against doing that in production code.
HTH
V.
I'd like to run some encrypted connections between some of my own servers. One can use Curl (or some other mechanism) to connect using HTTPS without SSL certificate verification. I'm using PHP, but the language probably isn't significant for this question.
I'm assuming using HTTPS without a SSL certificate is atleast more secure than doing the exact same connection over plain HTTP, since atleast it's encrypted and an evildoer would have to make a much larger effort to intercept en decrypt the information.
As far as I know an SSL certificate only says "this trusted third party says the server you connect to is owned by the guys that claim to own it". If I connect using my own domainname or IP address, I know I'm the owner. What additional value does an SSL certificate provide if I'm the owner of both ends of a connection?
Not verifying the identity of the server you connect to leaves the connection open to potential MITM attacks. SSL/TLS can be used without certificates (with anonymous cipher suites), but they're insecure (and disabled by default); as the TLS RFC says: "Note that this mode is vulnerable to man-in-the-middle attacks and is therefore deprecated."
In addition, the HTTPS specification itself expects there to be an X.509 certificate.
Checking the identity of the remote party is a necessary element for securing your system. It's not very useful to exchange data secretly with a remote party who may not be who they claim they are (even if the secrecy is guaranteed).
This being said, you don't have to go via a commercial CA. You can either use self-signed certificates, which you would have to import individually into each client as trusted certificate, or create your own institutional CA. There are tools to do this, ranging from OpenSSL's CA.pl (see man-page), TinyCA or OpenCA amongst others. Some operating systems also provide their own small CA capabilities.
If I connect using my own domainname or IP address, I know I'm the
owner. What additional value does an SSL certificate provide if I'm
the owner of both ends of a connection?
The certificate assures you that you're indeed connecting to your machine and that the traffic hasn't been intercepted. That's why you need to check that it's a certificate that you recognise.
SSL certificates are more for the piece of mind of your customers or those using your site. In either case, the data is being transmitted over the same connections - it's just a matter of whether or not a third party is certifying you as being safe.
At my last job, we did all of our internal data transfers at my last job via https/ftps but did not have an SSL certificate until very recently. Since the data transfers were internal, it made no difference.