Enabling TLS encryption and POST requets for HTTP API for more network security.
Features
TLS encryption for transport (HTTPS)
POST requests for HTTP-API usage so commands could not be sniffed on the network (TCP/IP level) – obsolet if strict TLS v1.3 implementation is in place
Reason
Encryption of data transmission even in an local home network must the encryptet for security and trust. The Smart Lock is a security relevant device an therefore confidentiality and integrity of the communication must be default. The Bridge has 230V power supply and therefore power consumption is not a limitation not to use TLS and other security lilke authentication and/or autorization.
POST requests ensures that the API payload could not be sniffed like using GET requests, where the payloud is the URI parameter.
You are even in violation with your own statements on security of the Nuki system:
" How secure is Nuki?
Smart Lock communication is end-to-end encrypted. Our security standards are comparable with those of the online banking sector. In this regard we have been audited and marked out by independent security experts and institutions.
"
No, I do not The request as you can see in my origin post is for the NUKI Bridge HTTP API Interface.
The information you posted is only valid for the communication between the Smartlock and other devices using bluetooth and hopefully for the external HTTP-IP for communication with the NUKI Cloud backend system.
And there is no HTTPS or any other security mechanism in place. And die Token is transported unsecured by HTTP GET and everybody in the corresponding network of the bridge is running can easily perform a man in the middle attack getting the token and full access to the bride HTTP API Interface.
But can you ensure for every time in your “home” network nothing malicious is running? Like a hacked router, PC or Laptop, Smartphone (e.g. friends attached to your wifi), Smart-TV, Smart-Whatever-Device? So you currently need to setup a separated local API interface network to “secure” the API communication.
You can switch to using the new hashed token introduced in the bridge beta firmware 1.12.0/2.2.0 (also part of the new public version which is likely to go live today).
The request as you can see in my origin post is for the NUKI Bridge HTTP API Interface.