[tor-talk] Giving Hidden Services some love

[Jesse B. Crawford]

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 // jesse at jbcrawford.us
https://cs.nmt.edu/~jcrawford // jcrawford at cs.nmt.edu