2

My IoT Device is connecting to server using TLS. on Device side implementtaion (with wolfSSL) we are just passing CA (root) cert to validate/ authenticate the server! any specific identity of server is NOT being passed apart from the server url - that means server is being authenticated just via the CA root cert!

if a server is being authenticated just via a root cert, any other body (not ligitimate server) could present its cert and will be authenticated by my IoT device!

Isn't this implementation having security gaps? shouldn't the specific server identity be validated alongwith the cert?

3
  • 1
    "any specific identity of server is NOT being passed apart from the server url - that means server is being authenticated just via the CA root cert!" - but the URL is the identity. Usually it will be checked if the hostname in the URL is covered by the certificate. What other kind of identity you expect? "... any other body (not ligitimate server) could present its cert and will be authenticated by my IoT device! ..." - this is true only if somebody else could get a certificate from the same CA and for the same identity (URL). Is this the case? – Steffen Ullrich May 3 at 11:54
  • Thanks Steffen! I guess this clarifies my doubt. I am using a TLS library directly. was passing the root cert but not any url / hostname explicitly! but like you mention here "URL is the identity". so that needs to be pased and validated in addition to the root cert. – Akhilesh Gupta May 3 at 17:21
  • USe BearSSL for small devices, it is from our Bear – kelalaka May 3 at 18:25
3

When thinking of certificates, I like to compare them to a passport or driver's license. When you hand your ID to a police officer they will:

  1. Check for validity: Inspect the ID to ensure that it appears authentic; matches what they expect your country's ID to look like, has no evidence of tampering, is not expired, etc.
  2. Check that you are the card subject: Compare the photo against the person standing in front of them.

At this point they have "verified" your ID and can trust any additional information in it (ex.: Name, Date-of-birth, address, etc).


A TLS client validates a TLS server certificate in exactly the same two steps:

  1. Check for validity: Ensure that the certificate cryptographically chains to a trusted root, is not expired or revoked.
  2. Check that the server is the certificate subject: Do a "proof-of-posession" check (usually a digital signature) to ensure that the server has the private key matching the public key in the certificate.

At this point they have "verified" the certificate and can trust any additional information in it (ex.: the server host name in a DNS_Name SubjectAltName extension).


You say:

any specific identity of server is NOT being passed apart from the server url

The server has two pieces of identifying information:

  • Cryptographic public key, which is in the certificate, which you trust to be not tampered with if the certificate chains properly to the root cert.
  • The server URL.

So if both of those checks pass, then you know you are talking to the server with that domain name, as certified by the Root CA.

if a server is being authenticated just via a root cert, any other body (not ligitimate server) could present its cert and will be authenticated by my IoT device!

That is only true if your Root CA is issuing certificates for a given URL to people who do not actually own that URL. If that is the case, Stop using that CA, report them to the CA/Browser Forum, and find a more trustworthy CA to do business with!


Implementation notes:

Your crypto library does not know what URL you are trying to access, and therefore does not know if the DNS Name in the cert is expected or unexpected, but the application does! If you are using a framework or tool with an HTTP request API, it will likely do this check for you, though sometimes if you are working directly with a TLS library, you will need to write the code for the hostname check yourself.

Also, "trusting the root CA" is how PKI works. It's the only scalable model for trusting a server that you've never interacted with before. But maybe it's not for you. If your IoT clients are only interacting with a small number of servers, and you know at manufacture time what those will be, then you could look into certificate or public key pinning where you provision devices with a local database of servers and the public key that you expect them to use.

3
  • 1
    Thanks Mike for a detailed explanation! this indeed clarifies. – Akhilesh Gupta May 3 at 17:11
  • 1
    I guess my issue is on implementation side! I am using directly a TLS library, where I am not passing any host name, or domain name of server; rather only root cert is passed; which left me wondering how specific server identity is being authenticated! – Akhilesh Gupta May 3 at 17:16
  • @AkhileshGupta Great! Glad I could help! Then yes, your intuition was correct that something is not right here. Sounds like you need to add a hostname check to make sure the hostname in the cert (usually in the dNSName SAN) matches the URL you are trying to reach. – Mike Ounsworth May 3 at 17:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.