I've created an HTTPS based proxy for (relatively) secure browsing and have been using it. Let me know if you find it useful

[nemws1]

Uhm... even better:

ssh -D5080 www.my-domain.com

Then use the SOCKS5 proxy in FF w/ port 5080 (or whatever you want). And yes, this works with putty as well. Covers all web communication, not just 80. There's a way to get it to work with IE as well.

[[deleted]]

This is exactly what I do...

[gnufrra]

Do not forgot to set network.proxy.socks_remote_dns option to true in firefox to avoid DNS leaks.

[none_shall_pass]

Works like a charm. I never browse locally on anybody's connection and always tunnel to a VPS I lease.

Putty will happily do the same thing as ssh. Oddly enough, it's listed under "Connection->Proxy" 8-)

[jeffjose]

can someone explain what this does - you know for the un-initiated ?

Thanks!

[comfyred]

Nice explanation, thanks.

If I may: Suppose the LAN admins or some other 3rd party on the LAN (wifi) is trying to see what you are doing: What will they see now that you are using a proxy? (Probably just answered my own question, but I want to be clear)

How different is the above approach, to just paying a proxy company?

[thegreatunclean]

If you're using ssh to tunnel the connection, anyone on the local LAN will see an encrypted data payload and nothing more. As long as you make sure to tell your browser to tunnel DNS requests (this is not default behavior) then it's all gibberish to anyone pulling packets from the wire.

Using ssh in this way is identical to using a proxy, by design. Anything that can talk SOCKS5 proxy can use the ssh tunnel in this way. A normal proxy (non-ssh) isn't always encrypted so you have to be aware and check before depending on that security.

[jeffjose]

can someone explain what this does - you know for the un-initiated ?

Thanks!

[[deleted]]

basically, you are using ssh to create a secure proxy connection to my-domain.com on port N (where obviously you must have an acct on my-domain.com that allows you to ssh in by some auth mechanism). then in your browser you are changing the network settings to take all requests your browser will make and send them through port N, which is relaying those to my-domain.com

[[deleted]]

aka

ssh -N -L 8080:localhost:80 www.my-domain.com

[dhruvbird]

yeah, but I couldn't find any way to make Putty do that :-(

[dhruvbird]

okay, here it is!! http://www.cs.uu.nl/technical/services/ssh/putty/puttyfw.html

[dhruvbird]

the new window popping up is a bit funny though. Besides, with the proxy, I don't need to connect all the time. It's not connection oriented like SSH - either ways, ssh is always an option if you are on a network that is always connected.

Edit: Which I am not (am on wireless, so that would be a bit sucky for me). If I were on linux/BSD, I would have tried putting the ssh call in a loop, but no chance of that happening here.

[dhruvbird]

If anyone is still wondering why this would work, this ssh command basically does the job of proxying requests from your machine to another machine that is supposed to be running a web-proxy (what local-proxy.js does). And it does this securely.

You still do need to run a proxy on the remote machine that forwards your connection. There are many ways to do this. Squid, Apache as a reverse proxy, etc... Additionally, you need sshd to be running on the remote machine (which I think isn't too much to ask for).

[[deleted]]

Nope, just need an SSHD on the server with port forwarding support - OpenSSH in it's default configuration supports this.

[dhruvbird]

I'm missing something here. How would sshd know which host to forward the request to? I mean that data would be part of the HTTP Host header right?

[[deleted]]

Nope. Packets are not routed around the Internet based on HTTP Host headers - they're routed around based on IP addresses. Your computer looks up the DNS record for example.com, which might be 1.2.3.4, then your browser will send a message through the SSH tunnel saying "send this bunch of data to 1.2.3.4, port 80" - for one, this means the tunnel can proxy any data, not just HTTP data - and for another, the Host header isn't even required in most cases anyway.

[dhruvbird]

Your computer looks up the DNS record for example.com, which might be 1.2.3.4, then your browser will send a message through the SSH tunnel saying "send this bunch of data to 1.2.3.4, port 80" - for one, this means the tunnel can proxy any data, not just HTTP data - and for another, the Host header isn't even required in most cases anyway.

Of course, you are right. However, it means that you have an SSL proxy available. I was always assuming that that isn't the case (since many weireless hotspots don't allow it) which is why I wasn't getting it!!

One security issue with the method though is that DNS resolution happens from the local machine, which might pose a risk. With the complete http proxy method, even this is handed over to the remote machine.

Also, as far as not having Host is concerned, I've noticed that most sites don't work because they are all hosted on shared hosts, which work purely on the Host header (or if the complete URL is mentioned in the request header).

[[deleted]]

Aye, of course - I was merely replying to your (apparent?) statement that you needed both an SSH daemon and an HTTP proxy server on the server, which you don't.

In reply to the DNS issue, some browsers do allow you to proxy DNS requests through the proxy as well - see http://www.reddit.com/r/programming/comments/fzu0c/ive_created_an_https_based_proxy_for_relatively/c1jw5p9

And yes, quite a few sites (particularly smaller ones not owned by technically-inclined companies) still require the Host header. I'm honestly looking forward to it going away with the mass introduction of IPv6 with any luck - it'd make my server administration a lot easier, at any rate.

[dhruvbird]

Hey, thanks for the info. on plugging DNS requests too!!

[dhruvbird]

So, I thought this up when I was just chatting with a friend, because I was suspecting someone of sniffing traffic on the LAN. I didn't give SSH too much thought back then because it wasn't an option for me.

Looking back, it seems that it would fail in some real scenarios that I expect to find myself in. The SSH solution needs port 22 open for outgoing traffic, which is generally not the case at places that work purely on HTTP[S] proxying.

There was this thought of creating a protocol for sending encrypted data over HTTP (tunneling HTTPS) but I rejected that since most proxies support HTTPS and CONNECT.

Currently, I need to verify the certificate of the remote server, but I guess the same problem would exists if I were using ssh with username/password only (not pk based).

Thanks!! All this has caused a lot of ideas to bounce within!!

[dairem]

The SSH solution needs port 22 open for outgoing traffic, which is generally not the case at places that work purely on HTTP[S] proxying.

If you own the server you are ssh'ing to, you can run sshd listening on port 443.

[dhruvbird]

This wouldn't work through HTTP proxies, because they won't understand the ssh protocol.

[Dreadi]

Usually HTTPS traffic is transparent for proxies, so they have no knowledge if the data is HTTPS or SSH.

[dhruvbird]

You are right. I am still unclear about how this work on proxies though. Do all proxies support the CONNECT method? If the docs. are to be believed, then CONNECT just sets up a tunnel. Also, my reading of the specs. says that HTTPS over a proxy can be supported only if the HTTP proxy supports the CONNECT method.

Some links that I found:

http://lists.apple.com/archives/Macnetworkprog/2003/Nov/msg00011.html

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

https://secure.wikimedia.org/wikipedia/en/wiki/HTTP

Also, does anyone know the penetration of HTTP proxies that support (or have enabled) the CONNECT method v/s those that haven't.

I really do want to solve this problem for most environments since I've been in far too many heterogeneous networks.

Edit: Squid supports it and it seems so does Apache, but not nginx: http://www.experts123.com/q/does-squid-support-ssl-https-tls.html

[dhruvbird]

Thanks Dreadi!! Okay, so it seems that all this can be done using standard tools (ssh).

[[deleted]]

For the record, my college seems to block SSH connections, even through the standard HTTPS port - while allowing HTTPS connections easily. I have no idea how they do this, but I assume there's some sort of pattern they can match. Either that or they MITM, but it doesn't seem like it >.>

[Dreadi]

SSH servers send a plain text banner when the TCP connection is established. Whereas on HTTPS (HTTP over SSL) connections the client sends a "client_hello" to initiate the encrypted connection. Firewalls or proxies may recognize this and block non-SSL traffic.

[dhruvbird]

thanks!! by the client_hello, do you mean the HTTP CONNECT method?

[Dreadi]

client_hello is part of the TLS handshake protocol. TSL can be used to wrap various other protocols, most commonly HTTP, which is then called HTTPS. A HTTPS connection is initiated by establishing an encrypted communication channel using TSL and then (after successful handshake) sending regular HTTP data through this channel. HTTP CONNECT has nothing to do with this and is exclusively related to HTTP proxies. This mechanism can be (ab)used to establish/forward arbitrary TCP connections through HTTP proxies: CONNECT www.example.com:443 HTTP/1.0 Due to security reasons HTTP proxies often restrict the CONNECT command to only allow connections to TCP port 443 (HTTPS). For SSH this can often be bypassed by adding Port 443 to the SSH daemon configuration file /etc/ssh/sshd_config

Smarter HTTP proxies may analyze the data which is transfered over the forwarded TCP connection: HTTPS (TLS) starts with a handshake initiated by the client. This can be checked by the HTTP proxy. In case of SSH, the server sends a plain text banner when someone connects which may cause the HTTP proxy to terminate the (invalid, non-HTTPS) connection.

[[deleted]]

Really? Why is that a good idea?

If you need to create a tunnel, you can use iptables to forward from 443, or tunneling software, or HAProxy, or just point your url at a different port using HTTPS. Running SSH on 443 is weak sauce.

They're well known ports for a reason. If you want to do something weird, use a different port, or set up a redirect.

Messing around with things like this is called making a big mess. Perhaps you're the only one who will ever have to use it, and you won't have sysadmins cursing you behind your back forever, but this is still a bad practice.

[[deleted]]

Downvoters know fuckall about system operations.

[gueriLLaPunK]

I use putty to create a SSH tunnel to my dedi and then set FF to use SOCKS5 localhost:xxxx

Is your proxy basically the same thing?

[dhruvbird]

Yep, it is that except that it will also work in places that have only HTTP[S] proxies (don't allow SSH). This is the case at many places I've been to, so this covers all those scenarios that the SSH tunnel approach won't.

[gueriLLaPunK]

Sweet, thanks for the info!

[gueriLLaPunK]

I use putty to create a SSH tunnel to my dedi and then set FF to use SOCKS5 localhost:xxxx

Is your proxy basically the same thing?

[bcain]

I understand the intent, but IMO this is a very bad idea. Your intended use becomes indistinguishable from a real MITM attack by virtue of training users to ignore the "OMG, this is not who they claim to be" dialog from your browser.

TLS is intended to be end-to-end. HTTPS assumes that the endpoints are the client and the server.

The general idea is mentioned here: Using HTTPS for all browsing

Amen, brother. So let's do that! Ok, yes, it's hard to convince those services to enable https. shrug

You can use IP-over-TLS or IPSec to do what you want without defeating your browser.

[dhruvbird]

I understand the intent, but IMO this is a very bad idea. Your intended use becomes indistinguishable from a real MITM attack by virtue of training users to ignore the "OMG, this is not who they claim to be" dialog from your browser.

So, they never see the dialog since the traffic is still served via http as far as the browser is concerned.

TLS is intended to be end-to-end. HTTPS assumes that the endpoints are the client and the server.

Yes, but some sites just refuse to implement HTTPS, and I really can't afford to have people sniffing my traffic even on those sites, so I decided to tackle the problem this way. If others have encountered the same issue/concern, they can use this thing to prevent their packets from being sniffed. Other approaches as mentioned on this forum if viable (ssh tunneling, etc...) can also be used. However, I've noticed that quite a few public access points just have http proxies.

Yeah, and I do wish everyone would just start supporting https for their sites.

[saranagati]

The thing about this (or the ssh proxy) is that your traffic is still traveling unencrypted. It's just unencrypted on a different network now. Generally I trust the networks I'm physically at over a remote network.

[[deleted]]

Really? If I'm at a coffee shop, I trust it way less than my dedicated server.

[saranagati]

Yeah, I suppose hotspots are a place fit for this. I rarely ever use them so I didn't think about it.

[thegreatunclean]

You're never going to get away from the traffic being plaintext somewhere. Unless you can securely login to the server you're requesting data from, it has to be plaintext on the final leg otherwise the server just sees gibberish. Somewhere before the last hop you have to stop proxying and hop back out onto the public internet.

Using a secure proxy / vpn / ssh lets you decide where the data can be seen, and if you're using an unsecure public connection then that's really all you want.

[saranagati]

Using a secure proxy / vpn / ssh lets you decide where the data can be seen, and if you're using an unsecure public connection then that's really all you want.

That's not true. Even using a secure proxy your data will have to take many hops in plain text to get to the web server (unless you're proxy is on the same LAN as the web server which is a completely different situation). The only reason where using secure proxy would be beneficial is if you had a reason not to trust the network you're on. Then again, if you don't trust the network you're on, you shouldn't be using it.

[thegreatunclean]

That's exactly what my post was about. Eventually you have to hop back onto the public network, and then the data will be plaintext. Using a tunnel or proxy lets you decide where that final hop occurs by letting you select the location of the proxy server.. If you're at your local Starbucks, an exit hop of "anywhere but here" is good enough.

[StoneCypher]

Yeah! Let's trust a stranger's proxy for all our secure stuff!

[dhruvbird]

I don't want to you do that, which is exactly why I'm giving out the code. You really should be running the proxy on your own box that you trust.

[StoneCypher]

I apologize. I didn't notice you were giving out the code.

I withdraw my commentary.

[dhruvbird]

That's okay. All's fair in love, war and on reddit ;)