Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!


Click here to return to the '10.5: Set up OS X as an SSL-secured reverse proxy' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
10.5: Set up OS X as an SSL-secured reverse proxy
Authored by: amusingfool on Mar 12, '08 01:29:28PM
Sorry... Glossed over some details... The short is that it doesn't matter if the TiVo's web interface is https or not (except that if it was, you'd need to change the URL I mentioned in my first reply to https://localhost:9999/ ).

In more detail, this establishes an SSL tunnel from your (work? travelling laptop?) machine to the internet-facing web server. So it's encrypted while travelling over the public internet, but the communication between that web server and the TiVo (over your home network) is unencrypted. So this is actually an ideal situation.

Again getting back to that hypothetical HTTPS-enabled TiVo, that would mean that the channel would be doubly-encrypted on the first leg, and singly-encrypted on your home network.

As a side note, this can also be used as a strategy for browsing on a censored internet connection (say, over the Denver airport's WiFi). Just make that tunnel something like -L 9999:boingboing.net:80

And if you really want to get fancy (like, by establishing a dozen tunnels at once (possible, but rather cumbersome, over the command line)), take a look at the man page for the SSL config file (do 'man 5 config' from the command line, for those not familiar with man)

[ Reply to This | # ]
10.5: Set up OS X as an SSL-secured reverse proxy
Authored by: ianf on Mar 13, '08 02:54:17AM
In more detail, this establishes an SSL tunnel from your (work? travelling laptop?) machine to the internet-facing web server. So it's encrypted while travelling over the public internet, but the communication between that web server and the TiVo (over your home network) is unencrypted. So this is actually an ideal situation.
Well, I've just had a quick play with this and it works just as you say. Somehow I've managed to miss this fantastic bit off ssl/ssh functionality!

In short, it means rather than setting up a reverse-proxy alongside SSL, SSL itself can be used to bounce from your proxy machine to any bit of kit that's listening on the network!
Obviously it's more convenient to not have to manually set up the client side SSL connection every time you want to connect to the device on your LAN (which my method offers) but the simplicity of your method combined with the added security of the server only being available when you've manually set up a connection could be VERY handy. Thanks very much for opening my eyes to this :-)

Cheers,
Ian

[ Reply to This | # ]