On 2015-01-03 05:23, Matthew Puckey wrote: > <snip> > > Not sure I would use DNS as an example of reliable authentication. As > above though, do you think current or future users would be checking > who issed the certificate? I don't think the typical user would. In > that scenerio, I would hope the difficulty in creating a too similar > hidden service address would create enough difference for users to > notice; though I might well be wrong here. But I see your point. :)
What I mean is that the situations where DNS is compromised (malicious DNS server, malicious local network operator, malicious third party pulling a trick on the local network, etc...), while completely possible and important to protect against, are far less common out there in the wild than phishers using similar-but-wrong domains (we've probably all seen a usbank.com.abunchofhexcharacters.numbers.cz before). I realized that I missed something earlier. When I refer to SSL certificates fixing this problem, I am referring to extended validation (EV) certificates that validate legal entity, not to the various cheaper certificates that only validate domain. EV certificates tie a service to a real-world entity, typically by the CA validating organizational documents (articles of incorporation, charter, etc) and validating that the person who submitted the request is an authorized agent of the organization. The certificates then include as part of the principal not only the domain name of the host but also the legal name of the operator. What this means to users is that they get a green box in their address bar with the legal entity name of the hidden service operator, which gives them easy-peasy confidence that they are communicating with the right party, as verified by a trusted third party. Now, two HUGE caveats: 1) Facebook does not actually have an EV cert for their hidden service! they have an OV cert with O=Facebook, Inc. but for various (largely political but still largely valid) reasons Firefox does not trust the O field and considers OV certificates no better than DV [1]. So why does Facebook use SSL..? I don't know, perhaps they think that providing the O field is significant (I'd say that it isn't because browsers don't tell the user about it), or perhaps it's just for consistency with their open web presence. 2) Don't think that I'm an advocate of the present CA infrastructure, it's a terrible approach to the problem. But it is the approach that we have right now. :) Overall, what should be done? Layering SSL on top of the hidden service system is not a good solution to the problem, but I'm also not comfortable with just saying "users should be smart enough to validate that they have the right address" and relying on the difficulty in producing a near-collision address (keep in mind that many "important" hidden services do not have a vanity address at all or have only generated an address with a small number of chosen characters). Probably the best solution is that hidden services that are attractive for phishing/misdirection (just about anyone doing business in bitcoin for example) should implement measures like showing secrets to the user to prove the service identity, and users should of course beware. But this solution requires service operator and user participation, making it far less than ideal. Hopefully I made my meaning more clear. jc -- Jesse B. Crawford Student, Information Technology New Mexico Inst. of Mining & Technology https://jbcrawford.us // je...@jbcrawford.us https://cs.nmt.edu/~jcrawford // jcrawf...@cs.nmt.edu -- tor-talk mailing list - tor-talk@lists.torproject.org To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
