On 24/04/15 23:06, Roger Hågensen wrote: > On Tuesday, April 21, 2015 at 2:56:21 PM UTC+2, Gervase Markham > wrote: >> This makes checking in with the browser maker a necessary >> prerequisite for secure connections. That has problems. > > How so? Certificates have to be checked today as well (if they have > been revocated or not).
Yes, and this has privacy problems too. Hence the move towards OCSP stapling, which does not. >>> 3. When the user later connect to a server that support automatic >>> encryption, the browser sends a (public) session key that the >>> server should use, this key is signed with the browser >>> installation key, the server can verify the signature and that >>> this key is not modified by checking the certificate server. >> >> What you just built is a unique identifier for every browser which >> can be tracked across sites. > > How can this be tracked? This can be tracked just like any other > client certificate can be tracked currently, no difference. Right. And that's one reason why people don't use client certificates! :-) Client certificates allow users to be tracked with 100% accuracy across every site which requests the cert. Which is why IIRC, by default, users are prompted in Firefox before sending a client certificate. > DNSSEC exists and should help mitigate who you are talking to issue. And is not fully deployed, and certainly not where it's most needed, at the endpoints. > Also certificates have been falsified (didn't Mozilla just untrust > all certificates by a certain certificate issuer recently that > allowed fake Google.com certificates to be made?) "Sometimes certs are misissued -> certs can never be trusted" is not good logic. > Also with certificates like the free ones from StartSSL the only site > identity you can see is "identity not verified" yet the connection is > still HTTPS. The domain name is the site identity for a DV certificate. > DNSSEC enabled (does all latest browsers support that?) So one can be > relatively sure to be talking to skuldwyrm.no without https. Perhaps, in this one case, if Firefox checked DNSSEC, which it doesn't. But you would have no guarantee of content integrity without HTTPS - an attacker could alter the content during transmission. > What I'm proposing is no worse than automatic domain verified > certificates currently are. Then why re-engineer the entire secure Internet just to get something which is "no worse"? Gerv _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
