Deepweb - how to get in

>>36219
>any advices how to be safe in deepweb
Make sure that, if you're connecting to the clearweb through tor, you're ALWAYS going straight through https (either with https-everywhere for its whitelist, or entering the full https://whatever path for those that aren't). If you don't, any of the layers you're going through can gather all of the data you've inputed in those pages. And even if the page automatically redirects you to https, using tools like sslstrip, malicious layers can make it look like they're outputting SSL when they're actually receiving your traffic in the clear.

>pages worth visiting?
Haven't hit it since the FBI killed some of the interesting stuff, and then everything else that was interesting closed out of fear.

Tor is still great for shit like anonymous communications (in the way tails uses it, for example) though.

>>36231
>malicious layers can make it look like they're outputting SSL when they're actually receiving your traffic in the clear.
No they can't, that's what certificates and CAs are for.

Only the server with Google's certificate can make a connection that makes your browser say it's connected to Google over https.

If you just click "derp, okay" when you get a certificate error, then you get what you deserve.

>>36219

Disable javascript

>>36351
>No they can't, that's what certificates and CAs are for.
And that's what sslstrip does. It hijacks your connection before the site redirects you to SSL, making the site believe it's giving you SSL while it's giving it to the MITM, who you communicate with in the clear.

Go watch Moxie's sslstrip conference. It's called something like tricks to beat ssl, or something like that. He directly attacks tor nodes with it.

>>36392
>before the site redirects you to SSL
But the site never redirects you to SSL.

You either enter the URL with its https prefix, or you follow a link with the https prefix, or your browser autocompletes your history with an https prefix.

You'd have to intentionally use http to connect to a site that you know uses https, then intentionally ignore that it's not https even though it usually is.

>>36402
>You either enter the URL with its https prefix, or you follow a link with the https prefix, or your browser autocompletes your history with an https prefix.
What? No.

if you type, say, "paypal.com" on your address bar, your browser takes you to http://paypal.com, which then redirects you to https://www.paypal.com (or whatever). That's why https-everywhere is so important - if you access a site from its whitelist without https, it redirects the address locally before you actually visit the site.

That's what sslstrip exploits: you go to paypal.com, and if you don't have something like https-everywhere or if the site isn't in its whitelist, then you visit paypal.com vanilla, going through the tor layers you're going through, and then, if any of those is running sslstrip, when paypal comes back with a redirection order, the MITM with sslstrip hijacks the connection, letting both your terminal and the server believe it's been connected securely, while the MITM is actually receiving and sending the traffic between the server and your terminal.

Seriously, go fucking watch moxie's sslstrip conference, god fucking dammit.

>>36409
>>36409
>letting both your terminal and the server believe it's been connected securely, while the MITM is actually receiving and sending the traffic between the server and your terminal.
But that's wrong.

The server thinks it's talking https and it is.
The client thinks it's talking http and it is.

The user can tell this is happening because the client does not think it's connecting securely, and lets the user know by the massively-obvious lack of any kind of SSL branding, the like of which even your grandma knows to look out for.

Without actually *being* paypal, the attacker cannot offer up paypal's certificate, and cannot make the browser display the happy green padlock and the happy yellow address bar and the happy "paypal inc" EV box.

For sites the user has already visited that have sent an STS header (like, say, paypal), the browser will redirect to https *itself*, never even try to make an http connection, and raise a massive red error page if for some reason https doesn't work.

https://en.m.wikipedia.org/wiki/HTTP_Strict_Transport_Security

>>36425
Yes, and that is what sslstrip is for, god dammit. To fake that shit.

OK, fuck it, I'll look for that conference for you. Again, the shown exploit was ran on tor:
https://www.youtube.com/watch?v=MFol6IMbZ7Y

Disable everything you can disable in NoScript; run zero plugins - Malicious javascript and plugins can exploit your browser
Don't download shit without carefully examining it first
Use the Tor Browser Bundle - your browser probably has a ridiculously well identifying footprint. The Tor Browser Bundle will look like every other browser heading to hidden services, so you'll blend in and not be detected.
HTTPS Everywhere - to defeat sslstrip (more below)

>>36515
moxie is wonderful and I absolutely love his work, but you're not really understanding how sslstrip attacks on Tor work.

>using tools like sslstrip, malicious layers can make it look like they're outputting SSL when they're actually receiving your traffic in the clear
this is untrue of sslstrip. it won't *look* as if you're connected over SSL from the browser perspective. sslstrip as the MITM proxy connect to the browser using HTTP, not HTTPS, so the browser doesn't see "https" or the little lock icon by the browser bar. Typing "https" manually or using HTTPS will protect against sslstrip (which basically acts as a MITM proxy that changes ever "https" url to an "http" url so the user never goes to an https link on a webpage)

However, using fake certificates, one can have the browser communicate with the MITM proxy using SSL and get then appearance of using HTTPS, but generally these will give off a certificate error, unless they're quite well done (certificate signing vulnerabilities, acquiring the actual certificate). Typing in "https" manually or using HTTPS Everywhere won't protect against these attacks.

>...going through the tor layers you're going through...
>...malicious layers can make it look...
Only the exit nodes can do this. Exit nodes are not "layers"

Additionally, OP is asking about "Deep web" browsing, which means he will be browsing .onion addresses, which do not use SSL (as it's unnecessary due to the encryption inherent in the connection)

>>36618
That conference I linked actually discusses using fake certs to mimic SSL. But this one expands a lot on it too:
https://www.youtube.com/watch?v=ibF36Yyeehw

And it's all implemented after running sslstrip.

>Typing in "https" manually or using HTTPS Everywhere won't protect against these attacks
They will though, because the man in the middle using sslstrip doesn't get the chance to strip SSL, as you're going through SSL directly instead of being redirected to it.

>Additionally, OP is asking about "Deep web" browsing, which means he will be browsing .onion addresses, which do not use SSL (as it's unnecessary due to the encryption inherent in the connection)
Yeah, but OP asked how to be safe, and this is an important thing to be aware of if you're using tor: if you use it on the clear web without being properly careful, you're gonna get your data stolen.

>>36648
>They will though, because the man in the middle using sslstrip doesn't get the chance to strip SSL, as you're going through SSL directly instead of being redirected to it.
The attacks I'm referencing with that statement aren't the sslstrip attack (the paragraph above that deals with sslstrip: "Typing 'https' manually or using HTTPS will protect against sslstrip"). The attacks are fraudulent certificates, which are basically as follows

user <- HTTPS using fraudulent cert -> MITM <- HTTPS using legit cert -> web server

the MITM doesn't have to strip anything. When you browser sends the SSL request, the MITM proxy works its fraudulent cert magic to impersonate the web server, allowing it to use the HTTPS protocol while still snooping your data.

>And it's all implemented after running sslstrip.
sslstrip is superfluous to certificate attacks. There's no need to use it, though the work it does is tangentially related to fraudulent certificate attacks.

>if you use it on the clear web without being properly careful, you're gonna get your data stolen.
Some time ago, some researchers actually tested for exit nodes using sslstrip and providing fraudulent certificates. I don't remember the exact number, but it turned out that very few exit nodes were actually performing those attacks and many that did would also only occasionally do it, presumably to remain less detected. A caveat of the research is that there's no way to determine if an exit node is snooping someone's HTTP traffic (as there's no change to it) or if an exit node is providing "valid" certificates (as in, ones that aren't setting off the "hey this cert isn't the right one" flag).

I actually used Moxie's tortunnel program to perform a smaller-scale replication of their research and found the same was true at the time I did it. So, while it is certainly a thing to worry about and protect against, you're not really that likely to have your data untampered with when using Tor to browse the clearnet.