We’re rewarding the question askers & reputations are being recalculated! Read more.

Hot answers tagged


See ticket 7707 for why we added that diagnostic log message in. In short, we were worrying that our round-robin bandwidth allocations would spread bytes too thin over all the connections we write out onto, making the overhead from TLS record headers too high a fraction of the overall bandwidth we use. This log message is telling you how many extra bytes ...


One possible solution is to disable the offending cipher by visiting about:config and setting the ciphers you don't want to false. Something like: security.ssl3.rsa_fips_des_ede3_sha false You could also improve your security by allowing TLS1.1 and 1.2 which are disabled by default in Firefox: security.tls.version.max 3 See my blog post ...


The site is not quite right about the SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA cipher. As I wrote in my blog post on configuring SSL in a secure way this is not a bad cipher. It offers the same security as other cyphers which are considered secure by the HowsMySSL-site. So it is not necessary to disable it. When you want to disable it, enter about:config in the ...


Today, Tor is moving away from looking like TLS, with pluggable transports being the solution for censored users. Tor is moving to using stronger cryptographic primitives so looking like a browser is no longer the goal. Detecting Tor relays not behind pluggable transports is relatively straightforward. One of the ways is doing what you describe.


So far it's just something that might be useful for developers to collect. It's probably nothing that an individual user or relay operator would have to care about at this time. It's also not even clear yet what the answer to your question really is. As Roger explained in What is the "TLS write overhead" percentage reported in Tor log entries?, ...


The problem is very serious. One should not underestimate the potential security risk of this problem. The heartbleed SSL bug was there since December of 2011 till April 7 2014. Even now it is not practical to update everything at once. Please note that Tor people carefully state that these are their first thoughts. It will take a long time to fully ...


Found the answer in the official Tor Blog. From the article: "Tor Browser shouldn't be affected, since it uses libnss rather than openssl. But Tor clients could possibly be induced to send sensitive information like "what sites you visited in this session" to your entry guards. If you're using TBB we'll have new bundles out shortly; if you're using your ...


Tor doesn't use GnuTLS, but OpenSSL. So it is not affected by this vulnerability. You also might have heard about an attack on SSL (Triple handshake attack). Nick Mathewson wrote an analysis to tor-dev. According to him this also doesn't affect Tor.


If I understand your question right, you're wondering about the link protocol that relays use to talk to each other. This protocol ensures that relays establish exactly one connection to each other, not a new connection per circuit they carry. Doing it that way has two advantages. One is anonymity: Multiple circuits are multiplexed over such a connection ...


This is the hostname that is included in the SSL/TLS certificate. Tor doesn't use it for authentication, so it's just generated randomly.


Permanent exceptions can't be made in Private Browsing mode. Go to about:preferences#privacy and either uncheck "Always use private browsing mode" or select "Remember History." This will save your browsing history, download history, and save cookies by default. To fix, uncheck "Remember browsing and download history" and "Remember search and form history." ...


Every backport costs a significant amount of engineering time. It's not possible due to resource constraints to always track the latest, including libraries. Another point is that the more custom changes we make, the bigger the likelihood of introducing a bug becomes.

Only top voted, non community-wiki answers of a minimum length are eligible