tag:blogger.com,1999:blog-865923359735383241.post482848078304304476..comments2023-10-29T07:27:09.012-06:00Comments on Ccna final exam - java, php, javascript, ios, cshap all in one: Tunnel over HTTPSUnknownnoreply@blogger.comBlogger13125tag:blogger.com,1999:blog-865923359735383241.post-5433637725291058242012-06-04T20:34:27.046-06:002012-06-04T20:34:27.046-06:00Could you set up a middle man?
Run a small/free/c...Could you set up a middle man?<br /><br />Run a small/free/cheap instance in the cloud listening on 443 for SSH, then though that cloud instance tunnel to your home box on your favorite port - 22 or whatever.<br /><br />It'll add some latency I'm sure, but it solves the problem of leaving the original home setup intact.Userhttps://www.blogger.com/profile/11557173689529910046noreply@blogger.comtag:blogger.com,1999:blog-865923359735383241.post-21728516705575522162012-06-04T20:34:26.160-06:002012-06-04T20:34:26.160-06:00So, then, give proxifier a try (- it supports HTTP...So, then, give proxifier a try (- it supports HTTP Proxy Server)!<br /><br />http://www.proxifier.com/documentation/intro.htmUserhttps://www.blogger.com/profile/11557173689529910046noreply@blogger.comtag:blogger.com,1999:blog-865923359735383241.post-3543598424917419282012-06-04T20:34:25.615-06:002012-06-04T20:34:25.615-06:00Must work over port 443, without disturbing other ...Must work over port 443, without disturbing other HTTPS traffic (i.e. I can't just put the ssh server on port 443, because I would no longer be able to serve pages over HTTPS)<br /><br /><br />Is it possible to bind your HTTPS server to a different port? Depending on what it's used for, you may even be able to get around the problem of not being able to directly access it from work by just SSHing home and then using lynx from there.Userhttps://www.blogger.com/profile/11557173689529910046noreply@blogger.comtag:blogger.com,1999:blog-865923359735383241.post-21420302614382663142012-06-04T20:34:24.851-06:002012-06-04T20:34:24.851-06:00Since apache has no problem whatsoever with CONNEC...Since apache has no problem whatsoever with CONNECT when no SSL is involved, I turn off SSL features and I use stunnel to serve an https version of my site. This does not require any recompilation, and allows your site to serve https normally. So far, the cleanest workaround I know.<br /><br />See http://chm.duquesne.free.fr/blog/?p=281 for details.Userhttps://www.blogger.com/profile/11557173689529910046noreply@blogger.comtag:blogger.com,1999:blog-865923359735383241.post-37343043485587501622012-06-04T20:34:23.978-06:002012-06-04T20:34:23.978-06:00See:
SSH Through or Over Proxy
http://daniel.hax...See:<br /><br />SSH Through or Over Proxy<br /><br />http://daniel.haxx.se/docs/sshproxy.html<br /><br />http://www.agroman.net/corkscrew/Userhttps://www.blogger.com/profile/11557173689529910046noreply@blogger.comtag:blogger.com,1999:blog-865923359735383241.post-28165108136646747572012-06-04T20:34:23.270-06:002012-06-04T20:34:23.270-06:00Proxy tunnel may be your answer
http://proxytunne...Proxy tunnel may be your answer<br /><br />http://proxytunnel.sourceforge.net/<br /><br />lets say my ssh server is host.domain.tld and my works proxy server is 10.2.4.37<br /><br />I would add this to my local ssh config<br /><br />Host host.domain.tld<br /> ProxyCommand /usr/local/bin/proxytunnel -q -p 10.2.4.37:3128 -d %h:%p<br /> ProtocolKeepAlives 30Userhttps://www.blogger.com/profile/11557173689529910046noreply@blogger.comtag:blogger.com,1999:blog-865923359735383241.post-60132139616635653142012-06-04T20:34:22.436-06:002012-06-04T20:34:22.436-06:00I think you'll have to find a port that you...I think you'll have to find a port that you're not using currently that you can get out on, and listen on that. 443 is the obvious candidate, but you say that's not possible. What about mail (25, 110, 143), telnet (23), ftp (21), DNS (53), or even whois (43)?Userhttps://www.blogger.com/profile/11557173689529910046noreply@blogger.comtag:blogger.com,1999:blog-865923359735383241.post-53103222652984786432012-06-04T20:34:21.429-06:002012-06-04T20:34:21.429-06:00How about using 2 IP adresses on your machine?
Bi...How about using 2 IP adresses on your machine?<br /><br />Bind apache/https on one IP_1:443 and your sshd on the other IP_2:443?Userhttps://www.blogger.com/profile/11557173689529910046noreply@blogger.comtag:blogger.com,1999:blog-865923359735383241.post-91399908124315395232012-06-04T20:34:20.729-06:002012-06-04T20:34:20.729-06:00I'm really sorry for being the Devil's adv...I'm really sorry for being the Devil's advocate here, but if they are blocking ports at your work, its likely because they don't want people breaching security.<br /><br />Now if you get permission to open a tunnel from your boss, that's fine, but IF something happens, ANYTHING, and they figure out you have a tunnel, I can almost assure you, you'll become the scapegoat. So if I were you I'd not be opening tunnels at work if they are setting up firewalls against it.Userhttps://www.blogger.com/profile/11557173689529910046noreply@blogger.comtag:blogger.com,1999:blog-865923359735383241.post-16022437651633966142012-06-04T20:34:19.983-06:002012-06-04T20:34:19.983-06:00I use a set-up like Dag's that I got from here...I use a set-up like Dag's that I got from here:<br /><br />http://www.saulchristie.com/bypass-firewalls<br /><br />It mentions that the Apache bug has now been fixed but my install still had the problem. Luckily the article also mentioned you could work around this by just using stunnel to provide your SSL wrapping...<br /><br />So if you still have the Apache problem but want HTTPS wrapping, follow the info in the link above, then also install stunnel, create certs etc. and have it set to listen on port 443 and pass the unencrypted data out to port 80. Works perfectly for me.Userhttps://www.blogger.com/profile/11557173689529910046noreply@blogger.comtag:blogger.com,1999:blog-865923359735383241.post-9605009788371715112012-06-04T20:34:19.325-06:002012-06-04T20:34:19.325-06:00Set up OpenVPN 2.1 server at home, use port 443 (i...Set up OpenVPN 2.1 server at home, use port 443 (if you set up your home any HTTPS service at port 443, trigger OpenVPN's port-share option to handle both OpenVPN and HTTPS transactions at port 443; this feature is only available to non-Windows OS)<br /><br />Then, set up your OpenVPN client on your laptop in road-warrior mode to access the OpenVPN server at home. You will be able to call home or anywhere you like within a secure VPN network you've created with OpenVPN. It is no longer required to use SSH for this purpose.Userhttps://www.blogger.com/profile/11557173689529910046noreply@blogger.comtag:blogger.com,1999:blog-865923359735383241.post-56626360963839015342012-06-04T20:34:18.628-06:002012-06-04T20:34:18.628-06:00You should be able to use iptables to forward ssh ...You should be able to use iptables to forward ssh traffic from your work machines to ssh while all other machines attaching to your home server on port 443 get the Apache server.<br /><br />Try a rule like this:<br /><br />iptables -t nat -A PREROUTING -p tcp -s 111.111.111.111 --dport 433 -j REDIRECT --to-port 22<br /><br />Where 111.111.111.111 is your office computer's ip address.<br /><br />That all assumes you're running Linux >= 2.4, which you should be by now. It's been out for almost a decade.<br /><br />Documentation for iptables is at http://www.netfilter.org.Userhttps://www.blogger.com/profile/11557173689529910046noreply@blogger.comtag:blogger.com,1999:blog-865923359735383241.post-60468893341642753742012-06-04T20:34:17.732-06:002012-06-04T20:34:17.732-06:00Find out why the company has such a restrictive po...Find out why the company has such a restrictive policy. It might be for a good reason.<br /><br />If you still find that you want to bypass the policy, you could write a small proxy that will listen on your server on port 443 and then, depending on the request, will forward the traffic either to your web server or to the SSH daemon. There are two catches though.<br /><br /><br />To determine whether it's an HTTPS request or an SSH request, you need to try to read some data with a (small) timeout, this is because TLS/SSL handshakes start with the client sending some data, whereas the SSH handshake starts with the server sending some data. The timeout has to be big enough to delays in delivering the initial data from the client in the TLS/SSL handshake, so it'll make establishing SSH connections slower.<br />If the HTTP proxy in your company is smart, it'll actually eavesdrop on the expected TLS/SSL "handshake" when you CONNECT to port 443, and, when it detects that it's not an TLS/SSL handshake, it might terminate the SSH connection attempt. To address that, you could wrap the SSH daemon into an TLS/SSL tunnel (e.g., stunnel), but they you'll need to differentiate requests based on the TLS/SSL version in your client request to determine whether to route the TLS/SSL connection to the web server or to the TLS/SSL-tunneled SSH daemon.Userhttps://www.blogger.com/profile/11557173689529910046noreply@blogger.com