before explaining my scenario … the direct question :
is there a bundle of certification autorithy (CA) certificates in net mf or in the GHI ad hoc firmwares ?
Why this question ? Read following …
I’m working on a project with AMQP protocol (instead of HTTP REST APIs) and Microsoft Azure Service Bus (queues, topics and event hubs) using the AMQP.Net Lite library (http://amqpnetlite.codeplex.com).
The Service Bus needs an SSL/TLS based connection for sending and receiving messages but I see that this connection is established in a very simple way … and it seems without any check !
The library uses the following code to execute authentication …
null is the client certificate (in this way we don’t want client authentication)
noVerification is false at runtime, so the parameter is VerifyPeer
usage of default SSL protocol
Now … during the SSL handshake, the server sends its certificate (inside a chain with two other CA certificate) and the client needs to verify it. To do that, the client needs a CA certificate so that with its public key it can verify the signature of the server certificate just received.
The AuthenticateAsClient method used in the library doesn’t have a collection of X509 certificates as CA certificates (there is another overload with this parameter but not the version used in the library).
So, why the authentication works fine !??
I think that there are two possibilities :
the method doesn’t execute any check … and it could be a very big problem ! Thanks to SSL I encrypt my data but without server authentication I don’t know if I’m talking with the right server I trust !
the netmf or GHI firmwares have a CA certificates bundle onboard (like our PCs)
Another strange behavior is that after established TCP connection with the right hostname, if I change at runtime the hostname parameter for AuthenticateAsClient (ex. from “myservice.servicebus.windows.net” to “helloworld”) … the verification works !!! There isn’t any check on the hostname in the server certificate !
It seems to be a big security issue … or I’m wrong because I can’t see in the right direction ?
Using my M2Mqtt library, I have always used the AuthenticateAsClient overload that takes CA certificate to be sure to verify the server certificate (MQTT broker).
May be you should export the certificate chain from a PC into a .cer file and include that into your application resource folder. You may also have to set the SSL seed on the device using mfdeploy. The device clock will need to be correct.
The problem isn’t that it doesn’t work … but the problem is that it works !!
It works without a CA certificate passed as parameter to the AuthenticateAsClient … so the question is if it is using a CA certificates bundle that is in the net mf firmware (base or GHI custom).
@ ppatierno - We don’t really change the SSL code beyond adding it to a device. If you pass null like you are then the NETMF code in the firmware ships a lot of checks. It is possible it was designed so that null means you do not want to verify the server.
As far as I know, NETMF does not maintain an internal list of CAs.
the null parameter is related to the client authenticaton. You can pass an X509 certificate to send to the server (if you want client authentication) or null (like me) if you don’t want client authentication but only server authentication.
However, you confirmed me that GHI doesn’t add anything to the SSL stack and doesn’t add a bundle of CA certificates.
So … this bundle could be in the net mf … or AuthenticateAsClient has a big bug !
@ ppatierno - There are definitely root-certificates included in NETMF. Because some certificates work out of the box and some don’t. The SSL stack seems to be outdated, which could explain that some root-certificates are not handled properly.
on our experience I think you are right … but I’d love to have an official reply by Net MF team … I will post the same question to them.
I posted here first because my idea was that GHI injected CA certificates in their custom firmwares for Net MF.
Howerver, the bad thing is that if I change the host name “on fly” before calling AuthenticateAsClient … the authentication works fine even if the host name isn’t the same in the server certificate ! This is a bad thing !
SSL protocol is based on a asymmetric part (based on certificates exchange related to public/private keys of the peer) used for authentication of the peers and to exchange symmetric part for encryption during the communication.
Asymmetric algorithm is slow for encryption so it is used only during SSL handshake but after that, the peers (client and server) use a symmetric algorithm to encrypt data with a related symmetric key they generates based on information exchanged during SSL handshake.
Encryption is based on PRNGs (pseudo random number generators). They are pseudo random and not “real” random so they need an initial seed to set before starting to generate a sequence (remember that if the seed is the same … the generator generates the same random sequence).
The update SSL seed function executes this operation.
Of course it is only an introduction to the SSL stuff and you can deep into it.
which is absolutely the right thing to do. I just wanted to make sure others interested had an easy way to see the discussion… for me, I am interested enough to watch from afar but don’t have the expertise to participate, so the link was enough.