Why is the Certificate fingerprint needed for HTTPS POST requests?

[Juraci]

Basic Infos

Hardware

Hardware: Nodemcu ESP-12E

Description

Problem description

Need to update the code from all Nodemcu ESP-12E devices whenever the SSL certificate of my endpoint changes, otherwise all devices that need to POST (over https) using the HTTPClient will start to get HTTPC_ERROR_CONNECTION_REFUSED response.

The URIs that I need my devices to communicate to change their SSL certificate every 3 months or so. It is extremely burdensome having to go to each device and update their certificate fingerprint.

My questions are:

1. [Potentially dumb question] Why is the certificate fingerprint required for POST requests over https? I don't see this requirement in other libs, you just have to pass the URI of the endpoint and that is it.
2. Is there a way to get around having to pass the certificate but still communicating through https?

[Potato-Matic]

I've had the same issue for a long time, and posted about it in the CA cert thread i think. It would be great if there were a way around this, since I do't know the status of that anymore...

[davisonja]

To verify the HTTPS connection is who you think it is (and it claims to be) you need to verify the certificate in some way. The fingerprint is used to do this. Presumably it's irrelevant if you don't care about someone having hijacked your connection (man-in-the-middle). If your system has a bunch of root-authority information/certificates it could perform the full chain verification (as a 'desktop' computer does) but typically these embedded systems don't. Particularly if your system is permanently connected to the internet an alternative might be to have an OTA http update that means you can centrally change the certificate and have the change propagate out to your devices (it's my approach)

…

On Tue, Apr 25, 2017 at 10:21 PM, Matt ***@***.***> wrote: I've had the same issue for a long time, and posted about it in the CA cert thread i think. It would be great if there were a way around this, since I do't know the status of that anymore... — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3157 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAN_Ay-FFAd7XJXWHlB67uByzziB1Yx9ks5rzckpgaJpZM4NEXAf> .

[igrr]

That got me thinking... what if we include fingerprints of root certificates into the program and check them instead? SHA256 fingerprints of all the root certificates in a typical root cert store would amount to a few kB, so we can bundle them with every firmware without much trouble.
Then the application will not need to specify website fingerprint any more.

[davisonja]

That's a nice adjustment, if fingerprints are a viable alternative to the full certs... Extending that such that the library automatically used "built-in" root-cert-fingerprints and could be given a secondary store of 'user' root-cert-fingerprints and you neatly cater for 'official' certificates and self-signed ones without a huge increase in complexity.

…

On Wed, Apr 26, 2017 at 3:58 PM, Ivan Grokhotkov ***@***.***> wrote: That got me thinking... what if we include fingerprints of *root certificates* into the program and check them instead? SHA256 fingerprints of all the root certificates in a typical root cert store would amount to a few kB, so we can bundle them with every firmware without much trouble. Then the application will not need to specify website fingerprint any more. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3157 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAN_A16Yz-FLBELj1FwJunj7UyJX0RH-ks5rzsD7gaJpZM4NEXAf> .

[Juraci]

@igrr that would be awesome.

[igrr]

Unfortunately, my above suggestion/proposal about bundling root certificate fingerprints with the framework doesn't seem to be viable. Most web servers are configured to serve all the certificates in the certificate chain, excluding the root certificate. The last certificate in the chain references the root certificate, but it is assumed that the client has the actual certificate locally.

For example, api.github.com sends a chain consisting of two certificates:

 0 s:/C=US/ST=California/L=San Francisco/O=GitHub, Inc./CN=*.github.com
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA
 1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA
   i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA

and the client is supposed to have the 'DigiCert High Assurance EV Root CA' stored locally.

[igrr]

More thoughts about this... For each root certificate we really only need to store the public key, and subjectKeyInfo hash (SHA-1) as an index. That's about 300 — 600 bytes, depending on RSA key length used, per certificate. We can probably limit ourselves with 10-20 bundled certificates, choosing the most commonly used ones. Even 10k isn't that much in terms of flash size, and will only be used if one specifically requests this feature (for example, through client.useDefaultRootCerts() or similar function call).

[Jeroen88]

Still it would be great if the verify() could be skipped on a secure connection. E.g. Microsoft's Azure-devices.net uses a secure (encrypted) connection optionally without a server certificate. Of course this is less secure, because the server is not authenticated, but at least the data is encrypted. Open e.g https://iotcampau.azure-devices.net/ in a browser. The connection is secure (encrypted) verfified by Microsoft, however, no server certificate is present. Using a non-encrypted connection is not possible, because azure-devices.net is not listening on http.

[AhmedAdelHosni]

Is there any updates regarding this ?
I have the same issue that i need to update the finger print every 3 months.
Any thoughts how could I do this in a good way ?
I thought of a workaround to save the finger print in a remote http server and if your another ssl server is failing then go check if the fingerprint was changed or not use it instead .

[devyte]

BearSSL is merged in #4273 , with alternate BearSSL::WiFi* classes. Although axtls-based classes are still available and even the default, they are planned for deprecation and then retirement, hence won't be fixed. Any issues with BearSSL-based classes should be reported in new issues.
Closing.