Improved handling of subjectAltName certificate fields in future release

[markphaedrus]

This feature request is a follow up to #260 .

To quickly summarize, the dummy SSL certificate generated by Simple Web Server previously only had one subjectAltName: a URI-based altname for "http://localhost", which could never match an HTTPS connection. The fix I submitted for #260 changed this to two altnames: a URI for "https://localhost", and an IP for 127.0.0.1 .

I suspect that this will turn out to be an 80% solution. It won't handle some IPv6 cases, and it won't handle some cases where the user loads up the site using "https://mylocalPChostname:7654" rather than "https://localhost:7654".

I suspect that you could pretty easily turn this into a 99% solution, by using the same url_list generation logic that you use in getServerStatusBox, and creating a URL-based altname in the dummy certificate for each of the generated URLs. So if the Edit Server screen would have this list:

then the generated certificate should have type-6 altNames for "https://192.168.48.137:7654", "https://127.0.0.1:7654", and "https://KOBOLD:7654".

That should make the certificate correct for all except the very weirdest of cases. And yes, the user would have to regenerate the dummy certificate if they changed the server's port or the PC's hostname; but that seems like an incredibly reasonable limitation.

[terreng]

@ethanaobrien Just a thought: I could update the UI to replace the "Generate dummy cert" button with a checkbox called "Use auto-generated dummy cert" which disables the cert and key fields. It would also be checked by default. Then we could have the server generate a new cert at runtime / whenever the IPs change, instead of saving it as an option.

I have been thinking about getting rid of that button for awhile. This change would make it so that once you check "Use HTTPS", everything just works. I would also like to add an explainer for the thisisunsafe trick since that's essential to know.

[markphaedrus]

Sounds like a promising approach; just a caution: if a user wants to do what I did -- manually export the dummy certificate using the browser, and import it into the Trusted Root Certificate Authorities store, so that the certificate is completely trusted -- then the user is going to have to re-export and re-import the certificate every time it changes. So having the certificate change itself frequently would do more harm than good in that particular use case.

But I could see one way to address that problem too:

• Manually generate, on a one-time basis, a self-signed "Simple Web Server Dummy Certificate Signing Authority" certificate, and publish it on your website.
• Have the Simple Web Server code generate all the dummy site certificates it feels like generating, whenever it feels like generating them; but have them all list the "Simple Web Server Dummy Certificate Signing Authority" certificate as their parent certificate.
• Now a user has three choices, depending on their use case and their paranoia level:
  • Do nothing, and click through the security warning every time they load a Simple Web Server site.
  • Manually export and import site certificates on a one-time basis as needed, so that trust is restricted to just the certificates the user has manually chosen to trust.
  • Manually import and trust the "Simple Web Server Dummy Certificate Signing Authority" certificate, so that all the dummy site certificates then get automatically trusted.

[terreng]

That sounds like a great idea, thanks for suggesting it! Do you know if there are any security concerns with using the same self-signed root certificate for all users of Simple Web Server? I think it might be better if we have the program generate a root certificate on install, so that it's machine-scoped.

[markphaedrus]

It would certainly be more secure to have each copy of Simple Web Server generate its own root certificate. Absolutely. It just adds that extra bit of code complexity on the client side.

[terreng]

Ethan, we could implement this as a global setting, and/or we could generate a set of pem files that we store in the application data directory, next to config.json. Our docs could point to that directory to find them.

On top of that, we could implement a checkbox as I described in the comment above, using the local root certificate as a parent.

@markphaedrus I assume that only the child certificates would need subjectAltName, not the parent, right? That's the only way this would work.

[markphaedrus]

Correct. Only the child site certificates need subjectAltName. The parent certificates are authenticated completely differently -- in most cases, the certificates are distributed as part of the operating system and/or the browser. Since your certificate obviously won't be distributed that way, the user will have to take that extra step of telling the operating system/browser to trust the certificate. In Windows, for example, the user will have to use Certificate Manager to import and trust that certificate. But once that's done, then all the site certificates will be trusted too, as long as their subjectAltNames match up.

[ethanaobrien]

Here are my thoughts:

Just a thought: I could update the UI to replace the "Generate dummy cert" button with a checkbox called "Use auto-generated dummy cert" which disables the cert and key fields. It would also be checked by default. Then we could have the server generate a new cert at runtime / whenever the IPs change, instead of saving it as an option.

I'm not sure how to take this approach, since I do manually plug in some of my certs for internal testing subdomains. A second option may make sense but may also be confusing for some users

Do you know if there are any security concerns with using the same self-signed root certificate for all users of Simple Web Server?

It'd be as secure as http, though these are local testing certificates anyways. If your machine is compromised you're already in trouble.

Edit: missing the "root" keyword in this sentence. Using the same root cert probably isn't a good idea

On Windows (except via the MS store) and linux, since config.json is plaintext (I'm not saying we should encrypt it in any way - this wouldn't really be possible) Any application would have read access to config.json. Then again, to take advantage of this you'd already have to be compromised.

Ethan, we could implement this as a global setting, and/or we could generate a set of pem files that we store in the application data directory, next to config.json. Our docs could point to that directory to find them.

What do you mean by "global setting"?

[terreng]

I'm not sure how to take this approach, since I do manually plug in some of my certs for internal testing subdomains.

This is what I was thinking. By default, the option is checked, and the cert and key boxes are grayed out. But if you uncheck it, then you can still provide a custom cert and key just like before.

It'd be as secure as http, though these are local testing certificates anyways.

The security concern I was actually that trusting the root certificate could be a bad idea if your computer ever connects to other sites that use the same certificate. If we make it public, then that's a possibility. But if it's generated on your device, then noone else would have it.

What do you mean by "global setting"?

I mean a setting in the Settings menu of the application, alongside language and dark mode. These settings apply to the whole application. This is unlike server settings, which only apply to each server.

[terreng]

Maybe the checkbox should instead read "Use a custom certificate" and work the opposite way

[ethanaobrien]

The security concern I was actually that trusting the root certificate could be a bad idea if your computer ever connects to other sites that use the same certificate. If we make it public, then that's a possibility. But if it's generated on your device, then noone else would have it.

Yeah, that would open up a pretty big attack surface. Best to generate on-device

Maybe the checkbox should instead read "Use a custom certificate" and work the opposite way

I think this idea makes the most sense

[markphaedrus]

Also, if you fix this, world's smallest additional possible bug fix to make: it's weird that the localityName and organizationName are now "Simple Web Server", but the certificate name generated at line 3 still starts with "WebServerForChrome". It may have been for back-compat reasons; but if so, the new changes you're discussing are probably going to have larger back-compat ramifications anyway.