4 ms·

Like others, I'm not exactly inspired by this feature. I'm an advocate for HTTPS-everywhere, but I think we're quickly moving past the point of usefulness for m

Like others, I'm not exactly inspired by this feature. I'm an advocate for HTTPS-everywhere, but I think we're quickly moving past the point of usefulness for most people. On a personal level, as a developer, I actually find the ban on mixed connections on a web page much more frustrating. It's easy for me to get a cert for nginx for my side project. It's another thing entirely to figure out how to give my application server access to the certs in the "right" way so that the application can terminate wss:// connections. I have to figure it out, of course, because firefox will refuse to connect a ws:// connection on a https page.

vbezhenar 6y ago
I don't understand your problem. Nginx should proxy all connections including websocket ones. Just don't expose your application server and use nginx as a reverse proxy.
- aeturnum 6y ago
  I don't understand my problem either - if I did it wouldn't be a problem! I'm not here fishing for tech support, but this is a real thing I'm encountering and I don't know that expressing disbelief feels productive? The point I'm trying to express is that giving a cert to your webserver is often only the first step in a relatively complicated process of securing all you assets. I wish browser makers would ask about blocking insecure connections instead of doing it by default. If you're interested in the kind of thing I mean see below: ------------------------------------------------------------------------------------------ So, for example - I'm running a quart server on hypercorn for a side project. Just giving nginx the certs will not, for reasons I don't understand, allow a wss:// connection to successfully connect (returns a 400). The developer conversation around this[1] suggests giving the certs to the application server. I can confirm that this works, but again I don't understand why. [1] https://gitlab.com/pgjones/quart/-/issues/319 https://gitlab.com/pgjones/quart/-/issues/319
  - vbezhenar 6y ago
    It could be because Host header supplied by nginx to your appserver by default will be something like 127.0.0.1 instead of yourwebsite.com.

vbezhenar 6y ago

I don't understand your problem. Nginx should proxy all connections including websocket ones. Just don't expose your application server and use nginx as a reverse proxy.

aeturnum 6y ago
I don't understand my problem either - if I did it wouldn't be a problem! I'm not here fishing for tech support, but this is a real thing I'm encountering and I don't know that expressing disbelief feels productive? The point I'm trying to express is that giving a cert to your webserver is often only the first step in a relatively complicated process of securing all you assets. I wish browser makers would ask about blocking insecure connections instead of doing it by default. If you're interested in the kind of thing I mean see below: ------------------------------------------------------------------------------------------ So, for example - I'm running a quart server on hypercorn for a side project. Just giving nginx the certs will not, for reasons I don't understand, allow a wss:// connection to successfully connect (returns a 400). The developer conversation around this[1] suggests giving the certs to the application server. I can confirm that this works, but again I don't understand why. [1] https://gitlab.com/pgjones/quart/-/issues/319 https://gitlab.com/pgjones/quart/-/issues/319
- vbezhenar 6y ago
  It could be because Host header supplied by nginx to your appserver by default will be something like 127.0.0.1 instead of yourwebsite.com.