Hacking Out of a Network - Computerphile

“Only do this at home” 1min later… “imagine you are in a train”…

"do not try this at home" "no, only try this at home", lmao, I am somewhat conflicted on this

We need more technical content like this! Great job!

Students are the best people to ask about how to bypass networks.

This format of screen-sharing is soooo much better than other videos. Please maintain this format of showing everything on the screen. So helpful and so much easier to understand

"Let's get the OHP up." Smacked me right back to elementary school.

I feel like this is how many kids get interested in computers.

04:35 UFW is actually Uncomplicated Firewall . It's "only" a Python "wrapper" for iptables.

My professor 2 years ago tried to explain ssh tunneling for the same length of time as this video and failed miserably. Dr. Clegg explained in half the time and even talked about other ways of doing this while being easy to comprehend. Great video

10:54 Unfortunately, this whole section here about TCP over TCP is incorrect in this case. Yes, if you're tunneling raw IP packets over TCP (and there are ways to do this with SSH, for instance using the -w option, running PPP over SSH, or with OpenVPN over TCP, as well as a million other ways), you do end up with the TCP-over-TCP meltdown you are explaining quite correctly. But, if you're using SSH's "dynamic port forwarding" mode which emulates a SOCKS proxy, there is no TCP over TCP at all going on. There's TCP running between your client software and the SSH client's SOCKS proxy emulator, TCP running between your SSH client and the remote SSH server, and also TCP running from the remote SSH server to the tunnel destination. These are all seperate TCP connections, and none of them of them running "over" each other. They're conseptually connected end to end, not over each other. There's no raw IP packets going over the SSH tnnel, and thus no TCP. Only the data beloning inside the stream as multiplexed as multiple channels in SSH. TCP retransmissions will happen on every TCP stream, but there's no redunant layer of TCP happening end-to-end over the actual tunnel, and no duplication of retransmission for that reason. That said, because everything you're doing ends up passing through a single TCP connection, that can definitely be a bottleneck, but for other reasons.

I remember using proxy tunnels way back in the early 2000s. I found a bank in France that had full internet access and proxied in to that over port 8080.

One of the very few videos I have watched more than once. Please do more high quality content.

I just run a VPN server at home, and anywhere I've been (including China) I can just VPN back home and get full normal access to everything.

Yes, TCP over TCP is bad. But there is no TCP over TCP in this case. There are just 2 TCP connections in serial. If you use ssh -w, that would create a tunnel where you are doing tcp over tcp.

that's how network engineers are born.... trying to bypass censorship

I've used iodine DNS tunnel for years. It's not fast or efficient but it works. Nobody has ever noticed and none of the many environments I am familiar with monitor DNS traffic for stuff like this.

4:32 Nope, it's "Uncomplicated FireWall"

We used to do this SSH tunnel way back in 2007 to break out of the NHS network to connect to home. Was a 2nd line engineer and sick of 3rd line monitoring anything you did. Got more work done with that tunnel than without it.

Really nice video. This is what inspires people. And then you introduce a NGFW with SSL and SSH decryption and loose all the magic.

I did this years ago to get around my University's firewalls to play games online... :D