I wanted to implement One Way SSL in MQTT. From what I researched, in on way SSL, the client has a stored default cert. It will use this initially stored cert and compared it with the cert from the broker side. If the cert is valid, then they established a secured connection. However, our embedded software engineer says that the client side doesn't need cert, it will just have to get the cert from the broker side then it will use for a secured connection. To summarized, what I understand is the client has a stored cert, and it will compare it with the one the broker has. The engineer says the client doesn't a stored cert, it will just get one from broker.
He already tested it by connecting to our broker with any initially stored cert and it really worked. Now I don't understand how one way SSL really works.
SSL with MQTT works as it does with any other protocol.
There are 2* main modes
Server (broker) only authentication. In this case the client connects to the server (broker), the broker sends it's certificate to the client. The client checks the certificate is issued (signed) by somebody the client trusts, this proves the server (broker) is who it claims to be and can be trusted. The client and server (broker) then do key negotiation in order to set up an encrypted tunnel. The act of checking that the server certificate is issued by a trusted party is to check it is signed by a known CA (certificate authority) certificate, this means the client needs to keep a list of trusted certificates.
Mutual authentication of both client and server (broker). This is pretty much the same as before except the client also sends it's own unique certificate to the server (broker) this is also checked to see that it is issued by a known CA and the CN field is used as the user id of the client.
*There is also pre-shared keys mode which don't use certificates at all.
Related
For normal TLS the client will check that the server I am communicating with is actually on the FQDN matching the CN, hence if the certificate is for a different domain the TLS should not work by default as the certificate is not for this site.
For mTLS when the server is checking the client certificate, can it somehow check the client address matches the CN somehow or is it simply checking the cert matches the key and cert is trusted on the client side? ie if I use the correct client key/cert from any machine on the internet should the server connect if its configured to trust that certificate, or will it require the client to be somehow at specific address?
It depends on the specific use case.
In some cases mTLS is used in server to server to communication, for example with SIP (VoIP). In these cases the client certificate is often expected to contain the domain of the sender, similar to a server certificate. Keeping with the example of SIP: here the different systems can also switch roles (i.e. both sites can initiate a call) and what was former the client certificate is now used as a server certificate.
In other cases the subject is not validated during the TLS handshake but the users identity is extracted from the certificates subject and provided to the application. The application might then do additional checks, like allowing only users from a specific organisation encoded in the subject. Thus, the subject is still relevant even if it is not used inside the certificate validation during the TLS handshake.
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 have an app going into production. It has a java client and a java server, both of which are always the same, and under my team's control. We are using https.
Is it OK in this situation to issue a self-signed certificate and accept it on the client? Is there any risk there?
HTTTPS is to protect the connection between server and client and you don't control this connection fully just by controlling both server and client. If you accept any self-signed certificate just because you control server and client then you would also accept a certificate from a man in the middle, i.e. this would be insecure.
What you can do is to hard code the expected certificate in the client, i.e. certificate pinning. This way you only accept this specific certificate and a man in the middle attack using another certificate is not possible.
For a project I'm working on I have to generate web server certificate.
As I understand it, server certificates should contain the Server Authentication OID (1.3.6.1.5.5.7.3.1). But as I see all server certificates issued by well known issuers like Verisign contain also Client Authentication OID (1.3.6.1.5.5.7.3.2).
I tried to use certificate with only server authentication OID - seems it works fine.
Questions
Why is the client authentication OID needed for server certificates?
Is it needed for some legacy support or there is another reason for it?
The difference between the two is exactly how they're described.
For using a certificate as a server (on the receiving end of the connection), it must have the Server extended key usage.
In a 2-way SSL connection, where the client (on the initiating end of the connection) presents a certificate back to the server, it must have the Client extended key usage.
If you're never using the certificate as a client cert, you won't need the Client Authentication OID.
I think it is also useful to point out that one of the main distinctions between Client and Server certificates is that:
Server Certificates are used for encryption and decryption of data;
Client Certificates represent a user identity. That is, to prove the client's identity to a remote server.
I am somewhat confused as to how two-way SSL works. How does the client create its certificate to send to the server? Is it generated from the server and distributed to the client?
Also, what is the advantage of two-way SSL over one-way SSL?
Both certificates should exist prior to the connection. They're usually created by Certification Authorities (not necessarily the same). (There are alternative cases where verification can be done differently, but some verification will need to be made.)
The server certificate should be created by a CA that the client trusts (and following the naming conventions defined in RFC 6125).
The client certificate should be created by a CA that the server trusts.
It's up to each party to choose what it trusts.
There are online CA tools that will allow you to apply for a certificate within your browser and get it installed there once the CA has issued it. They need not be on the server that requests client-certificate authentication.
The certificate distribution and trust management is the role of the Public Key Infrastructure (PKI), implemented via the CAs. The SSL/TLS client and servers and then merely users of that PKI.
When the client connects to a server that requests client-certificate authentication, the server sends a list of CAs it's willing to accept as part of the client-certificate request. The client is then able to send its client certificate, if it wishes to and a suitable one is available.
The main advantages of client-certificate authentication are:
The private information (the private key) is never sent to the server. The client doesn't let its secret out at all during the authentication.
A server that doesn't know a user with that certificate can still authenticate that user, provided it trusts the CA that issued the certificate (and that the certificate is valid). This is very similar to the way passports are used: you may have never met a person showing you a passport, but because you trust the issuing authority, you're able to link the identity to the person.
You may be interested in Advantages of client certificates for client authentication? (on Security.SE).
What you call "Two-Way SSL" is usually called TLS/SSL with client certificate authentication.
In a "normal" TLS connection to example.com only the client verifies that it is indeed communicating with the server for example.com. The server doesn't know who the client is. If the server wants to authenticate the client the usual thing is to use passwords, so a client needs to send a user name and password to the server, but this happens inside the TLS connection as part of an inner protocol (e.g. HTTP) it's not part of the TLS protocol itself. The disadvantage is that you need a separate password for every site because you send the password to the server. So if you use the same password on for example PayPal and MyPonyForum then every time you log into MyPonyForum you send this password to the server of MyPonyForum so the operator of this server could intercept it and try it on PayPal and can issue payments in your name.
Client certificate authentication offers another way to authenticate the client in a TLS connection. In contrast to password login, client certificate authentication is specified as part of the TLS protocol. It works analogous to the way the client authenticates the server: The client generates a public private key pair and submits the public key to a trusted CA for signing. The CA returns a client certificate that can be used to authenticate the client. The client can now use the same certificate to authenticate to different servers (i.e. you could use the same certificate for PayPal and MyPonyForum without risking that it can be abused). The way it works is that after the server has sent its certificate it asks the client to provide a certificate too. Then some public key magic happens (if you want to know the details read RFC 5246) and now the client knows it communicates with the right server, the server knows it communicates with the right client and both have some common key material to encrypt and verify the connection.
In two way ssl the client asks for servers digital certificate and server ask for the same from the client. It is more secured as it is both ways, although its bit slow. Generally we dont follow it as the server doesnt care about the identity of the client, but a client needs to make sure about the integrity of server it is connecting to.