TheMindwareGroup writes: > I don't know the exact details of how SSL/certificates work and I > don't know about anyone else's opinion on this subject, this is mine > and it doesnt look good. If this document is true, it means that due > to a (massive) weakness in the way central certificate authoritys > work, putting huge trust in central authoritys, it doesnt take much of > a stretch of the imagination of why this system is bad. From what I > can gather it appears using fake and forged root certificates and > probably intentional collusion with governments, they have total > access to enter any ssl stream they like. In short ssl is there > playground, so even if ssl is used we still cannot trust it cos they > can get into any ssl stream they like. Im not sure if this is true, > cos i dont know how the key/shared secret is created, but the document > hints that it might be based on the servers ssl certificate.
Hi Shadowman, A lot of people have been talking about this lately, and it's true that the current system is problematic for these reasons. Fortunately, there are a number of mechanisms that are trying to address the problems and reduce vulnerabilities. Among others, you might be interested in http://www.certificate-transparency.org/ https://www.eff.org/observatory http://www.internetsociety.org/deploy360/resources/dane/ https://www.imperialviolet.org/2011/05/04/pinning.html https://tools.ietf.org/html/draft-ietf-websec-key-pinning-04 http://tack.io/ There are also things to try to create more visibility for end-users who are willing to scrutinize the certs they're given, like https://addons.mozilla.org/en-US/firefox/addon/certificate-patrol/ Many of these things still need some work, so there are a lot of opportunities for people to contribute to them. They each have the effect of making certificate authorities more accountable or less absolutely trusted in some way, and increase the chance that misissued certs will be detected, publicized, revoked, and investigated. > Wouldnt it be better to communicate with a "Public browser" running on > the exit node and have the public browser do the requests for you? > Like this... > > [Browser] ->Tor->Entry->Relay-> [Exit browser] ------------> [Server]. > > [...] > With this setup you communicate with the browser, the browser access's > the internet 2 seperate communication channels. The exit browser > acting as a air gap or filter, filtering rubbish out of the requests, > filtering rubbish out going and rubbish incoming. Cookies are only > stored on the exit browser, and all accumilated rubbish on the exit > browser can be dumped. Unfortunately, we don't know who runs the exit nodes, and some of them may be malicious. If a malicious exit node is running an "exit browser" for you, it could design the exit browser to do bad stuff to you instead of good stuff to you. Instead of removing "rubbish", it could actually add it, or in any case deliberately fail to protect you from it. I don't think the Tor developers would think it was safe to increase the amount of trust that Tor users have to have in the exit node operators. If anything, the trend has been to try to reduce it -- which is one of the reasons that we and the Tor Project have created HTTPS Everywhere: it reduces the scope of exit node operators' ability to see and tamper with your browsing sessions. -- Seth Schoen <[email protected]> Senior Staff Technologist https://www.eff.org/ Electronic Frontier Foundation https://www.eff.org/join 815 Eddy Street, San Francisco, CA 94109 +1 415 436 9333 x107 -- tor-talk mailing list - [email protected] To unsubscribe or change other settings go to https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
