[Tfug] chrome's fixation with ssl

[Zack Breckenridge]

Ammon,

Admittedly, your post just made me aware of HSTS. But searching around led
me to 'chrome://net-internals/#hsts' ... perhaps since you've specified the
HSTS header in your nginx configuration already, chrome somehow ended up
adding your host to the HSTS set? Maybe try querying for some combinations
(e.g. just your hostname, then your hostname and port)?

HTH,

Zack B.

On Fri, Dec 4, 2015 at 2:49 PM, Ammon Lauritzen <allaryin at gmail.com> wrote:

> So… I played with LetsEncrypt on one of my servers yesterday since they
> finally opened the floodgates. I’m happy with the end result, even if the
> tool needs a whole lot of work.
>
> However, I encountered something really annoying. The only real service
> running on the domain I started encrypting is a standalone daemon on a
> non-standard port that displays some diagnostic data for me via http. Now,
> Chrome forces https on this site as well.
>
> I’ve gotten used to it turning port 80 into 443 once it knows that a
> domain can ssl… but I’ve never seen it commandeer a non-standard port
> before.
>
> For reasons that don’t matter, I don’t want to stick the daemon behind
> nginx. I would prefer to leave it as plain old http on port not-80.
>
> I AM specifying the full standard HTST header in nginx… but does anyone
> know if the spec actually defines this behavior, or if Chrome is just going
> overboard? IIRC, it will remember and do 80->443 even if the server doesn’t
> specify Strict-Transport-Security.
>
> Is anyone aware of a way to tell it to chill out on this service, or am I
> going to have to fight with it?
>
> Ammon
>
> _______________________________________________
> Tucson Free Unix Group - tfug at tfug.org
> Subscription Options:
> http://www.tfug.org/mailman/listinfo/tfug_tfug.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tfug.org/pipermail/tfug_tfug.org/attachments/20151207/0602b167/attachment.html>