No, .onion sites are not using https/ssl by default. But the connection inside the Tor network is always encrypted, so it is not really necessary to use https for .onion sites. Exit nodes aren't used at all with hidden services, because the connection stays inside the Tor network until the hidden service is reached.
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:
You could also improve your security by allowing TLS1.1 and 1.2 which are disabled by default in Firefox:
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 ...
It's exactly the same excepting that no CA will sign your CSR (it'll be a self-signed certificate) and it's mostly superfluous because .onion is already providing end-to-end authenticate encryption.
Update to address comments and updated question:
There is no difference between the approach over tor or a dangernet site, you'd setup something like:
That's not a web site, that is IRC (internet relay chat). You need an IRC client to connect to it. http://www.irc-junkie.org/2009-12-31/howto-irc-anonymously-with-tor/ might help you with IRC over TOR.
If no further information is known, you should expect that an attacker can read all your memory. See the heartbleed challenge from Cloudflare as an example. They set up a webserver with a vulnerable version of OpenSSL. Some hours later several persons extracted the key. Fedor Indutny described his work. From his description you can see that he could read ...
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.
Tor only protects the traffic up to the exit node.
If there is some man in the middle at the exit node or after the exit node then he can intercept and modify the traffic. Since https is end-to-end encryption it will detect such attack. But if you simply accept any certificates even if the browser explicitly warns against it or if the attacker has access to ...
This is a clip from the emailed response I got back in May 2014 when I had the same problem.
I'm on a windows machine and I didn't see how the answer gets used to help me run a relay again even though I've run one many times before with no problem. But this MAY help you, and I'll hope for enough info in time to help me fix this W7 machine to run the Vidalia ...
You're not trying to speak SOCKS, the SOCKS port only speaks the SOCKS protocol.
Decimal 22 is hexadecimal 0x16, which is the initial byte of a TLS connection. Tor's SOCKS port does not speak TLS. You cannot arbitrarily add TLS onto the SOCKS connection.
No one can MITM between you and a localhost proxy without being an administrator or having privileges ...
Due to regression introduced in OpenSSL 1.1.1a. Openssl says fix in next openssl release:
Until then, workaround for coping with OpenSSL 1.1.1a added to Tor:
Can confirm that Tor 0.3.5.7 no longer issues these errors.
Look for this in the Tor log:
The OP gave the answer in the comments. I'll add the answer for completeness:
Tor Browser has set security.nocertdb in about:config to true. This means that the intermediate certificate store is only in memory. If you change this value to false, it will be possible to add new certificates.
Yes for my browser, those two configuration is disabled. I am sure that the rest also have the same settings too unless they tweaked it.
Why isn't this enable by default?
I find Tor lead developer, Mike Perry's comment in this ticket provides the most complete explanation of why it is disabled from his point of view:
For Tor's use case, the ...
At the moment the only way to get a trusted SSL certificate for a .onion domain is to buy an EV (extended validation) certificate.
For more info see: https://www.digicert.com/blog/ordering-a-onion-certificate-from-digicert/
Tor does not care about the traffic that passes over it. Anyone running skiddy/"whitehat" tools on the exit traffic can tamper with it in any way. However these tools cannot break TLS.
The exit can see and could tamper with any data leaving the Tor network, but it's visibility would be of TLS. If the security properties of TLS hold, they will not be able to ...
Define safe. If you're worried about your boss being able to see what you're doing in Tor, then yes, Tor will be safe.
Your Tor traffic will still be intercepted by your boss, but since the connection from you to the Tor network is triple-encrypted, your boss will only see a bunch of encrypted data going from you to whichever guard relay you're connected to....
Tor uses SSL to secure point-to-point connections between peers. The multi-hop onion routing protocol (with its separate layered encryption) is implemented over these individual links. Thus it was possible for Iran to block Tor connections simply by identifying the beginning of the SSL handshakes from a client to its guard nodes, and interrupting them. It ...
But if this is the case I don't see how SSL is related to Tor, since
they seemingly function on a different layer.
If you're doing some preliminary reading about networking, you're presumably looking at either the OSI Model or the Internet Protocol Suite. They're different ways of representing the network stack, and differ in the number of layers they ...
The SSL and Tor are not parts of one problem. But the reason of meeting them together very ofthen lays within the network security area itself. Let me explain it - maybe abit over-deep-digging, but there's no too long proves ;) So :
SSL = "Secure Socket Layer". It's a tool(kit), in another words, and in simplified ones, it cares about all the questions "how ...
Your second computer must have two separate ISP's with different IP addresses, and it should be no problem at all : you will use two virtual machines, one for "using net securely", you will connect to it's VNC through Tor for a first time via first Internet connection, and this VM will go outside through a second VM, that will be a Tor router, WAN-bridged to ...
You can see the certificate information and export the cert:
Click the lock,
You don't need to download two certificates and compare them (but you can if you want to). Export the cert as a file and then:
openssl x509 -noout -text -in filename ; where filename is the cert you exported.
You can ...
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.
There's no start-vidalia script in the current version of Tor Browser Bundle, so I don't know what you're running.
Before doing anything else, obtain a current copy of Tor Browser Bundle.
The official instructions say:
To run the Tor Browser Bundle, execute the start-tor-browser script:
Trying to start with a different script, even ...