Non-HTTPS usage for development

[moll]

Hey,

I'm implementing Web eID and after troubleshooting why the browser extension kept throwing NativeFatalError: Technical error, see application logs, I finally discovered the native component (this project) hard-codes the requirement for HTTPS — 

web-eid-app/src/controller/command-handlers/certificatereader.cpp

Line 142 in 9c5f9ff

void CertificateReader::validateAndStoreOrigin(const QVariantMap& arguments)

Could there be a configuration setting to relax that requirement for development, or at the very least, honor the so-called secure context classification the frontend web-eid.js relies on (window.isSecureContext)? The latter classifies localhost as a secure context and at least that can be proxied from the eID machine to the webapp machine. Of course that's a waste of development time, too, but at least it's a workaround.

I test drive the Estonian ID-card software on a virtual machine with the actual app server running in another virtual machine. Requiring HTTPS for development is just unnecessary fiddling with proxying for no benefit whatsoever.

Thanks!

[mrts]

Hi and thanks for the suggestion! Option to allow the http://localhost origin will come in near future in web-eid/web-eid-webextension#79. Hope this will solve your problem.

[moll]

Hey! Thanks. Can this be expanded to also permit non-localhost for development purposes? As I described, I use multiple VMs to test stuff and the server doesn't sit in the same machine as the ID-card software?

[mrts]

Considering the sensitivity of electronic ID operations, we prefer caution and will not introduce loopholes for insecure contexts. Since running a local TLS reverse proxy or using ngrok/localtunnel is easy, we’ve decided against relaxing the security checks.

[moll]

That's an odd stance given we're talking about options for developers. The solution you're effectively proposing is equally insecure — using a self-signed certificate for a local reverse proxy is, after all, easily MiTMable because who manually verifies the hashes of self-signed certificates while developing.

[mrts]

We understand the frustration, our development tooling isn’t perfect and yes, self-signed TLS isn’t secure if someone ignores warnings. Our concern isn’t developer setups but avoiding mechanisms that could accidentally weaken production security. Built-in loopholes tend to survive and become real attack surfaces, so we prefer to keep the core strict while still allowing developers to use the optional localhost-HTTP convenience mechanism.