[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-talk] Giving Hidden Services some love

Hash: SHA512

Well is Tor then for the typicall user. That commes no in to my mind. Maybe im wrong...

Am 4. Januar 2015 05:42:14 MEZ, schrieb "Jesse B. Crawford" <jesse@xxxxxxxxxxxxx>:
>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
>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
>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
>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.
>Jesse B. Crawford
>Student, Information Technology
>New Mexico Inst. of Mining & Technology
>https://jbcrawford.us // jesse@xxxxxxxxxxxxx
>https://cs.nmt.edu/~jcrawford // jcrawford@xxxxxxxxxx
>tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
>To unsubscribe or change other settings go to

- --
Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
Version: APG v1.1.1


tor-talk mailing list - tor-talk@xxxxxxxxxxxxxxxxxxxx
To unsubscribe or change other settings go to