Re: [webauthn] Clarify 127.0.0.1 in spec (#1204)

fyi:
>Ok:

    DNS for foo.google.com resolves to 127.0.0.1
    Server on 127.0.0.1:443 serves self-signed certificate for foo.google.com
    User enters https://foo.google.com, browser loads from local server.

I got this to "work" on debian for https://localhost in chrome, [once I enabled](https://stackoverflow.com/questions/7580508/getting-chrome-to-accept-self-signed-localhost-certificate) `chrome://flags/#allow-insecure-localhost`. I used the "Making and trusting your own certificates" instructions here https://letsencrypt.org/docs/certificates-for-localhost/. 

>     User presumably overrides the certificate error.

In chrome, there seems to be no recourse for overriding the cert error. The only way I got it to work was enabling the `allow-insecure-localhost` flag and restarting chrome. 

WRT:
> I would like to make a counter-proposal then: all domain names that resolve to 127.0.0.1 should have the same RP ID. 

To which I'd offhandedly (and sorta embarrassingly, given the security implications) replied: intriguing idea, thx -- I think we shud investigate this:

It seems to me we've now investigated/discussed this and there's not anything to add to the webauthn spec in regards to it. Presumably, on my machine here, I ought to be able to now run a webauthn-wielding webapp on localhost for testing or whatever purposes (tho it does require jumping thru various hoops, and I haven't tested the running a webauthn-wielding webapp as yet). Presumably, I could add further hostnames to /etc/hosts that resolve to 127.0.0.1 and create self-signed certs (or one cert with multiple dnsname subjectAlternativeName entries) for them and (I'm guessing) that'd work.






-- 
GitHub Notification of comment by equalsJeffH
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1204#issuecomment-493268212 using your GitHub account

Received on Thursday, 16 May 2019 23:46:22 UTC