Chrome 68 will mark all HTTP sites as “not secure”

Re:Chrome 68 will mark all HTTP sites as “not secure” by tialaramex on Friday February 09, 2018 @10:49AM (#16341042)

That deserves a hard stare. If I trust the certificate on my chat server to be _the certificate for my chat server_ that doesn't suddenly make it OK to present that certificate if you're claiming to be my bank, or my operating system vendor, or Hacker News.

The local device should have a _name_ and then we can issue it a certificate for that _name_ and know we're really talking to the same thing as last time. DHCP and other address allocation protocols don't (needn't) change the name.

[ Parent | on HN ]

Re:Chrome 68 will mark all HTTP sites as “not secure” by nybble41 on Friday February 09, 2018 @04:41PM (#16344079)

I think we should just take the same approach that I2P and Tor take for naming, and base the domain name on the public key. Local devices automatically get a domain like gmaf2cgbn3q2be3vaaytrev3qyxcksemkdxtzefq5bl3542uyf3q.local, which they can advertise via mDNS, and the browser accepts a self-signed certificate for a public key which matches this fingerprint just as if it were "domain validated".

The domain stays the same so long as the key does, so the user can bookmark the page for their own device and be sure that when they navigate back to that domain they're getting the same device and not some imposter—effectively making this equivalent to "trust on first use".

Edit: Changed "on the certificate" to "on the public key". It might be necessary to regenerate the certificate periodically, e.g. to update the expiration date, and that shouldn't affect the domain name.

[ Parent | on HN ]