Heya James, > Actually there should be very little difference between a VPN and SSL > telnet. After all, what is a VPN except TCP/IP encapsulated in an > encryption scheme and then encapsulated again in TCP/IP? SSL telnet is > the same idea, except that the telnet protocol is encapsulated with > encryption instead of the TCP/IP protocol. That's true. The security of the encryption is about the same between a VPN and SSL telnet. There are other factors besides the strength of encryption to consider: 1) Authentication. SSL uses a signed-certificate system to validate that the server is someone that you trust. That's because SSL was designed for web sites providing online shopping for consumers, and the goal was to give the consumer confidence that his credit card data was viewable only to the business that he was buying from. If you want two-way authentication, it's important that you remember to do the extra setup of requiring client-side certificates that the server trusts. Not hard to do but it's an important to do, because with telnet usually it's the server your protecting, not the end-user. It's been ages since I've used a VPN, and I don't remember how/if they do authentication. I would expect that they're similar, though. 2) Risk. The levels of risk between a VPN are usually very different. With a VPN, your whole network is at stake if the attacker breaks through. With SSL, only the telnet service on the one machine is at stake. You can solve this VPN issue with an additional firewall, but that adds complexity. 3) Speed. You can fit less data per-packet in a VPN connection because the TCP and IP packet headers are encrypted in the data of each packet. In effect, your passing two packet headers in each packed, reducing the amount of space for actual data. With SSL telnet this isn't happening. 4) Convienience. VPN allows access to the entire LAN, that means you can use it to do far more than just telnetting to one machine. That provides a much higher level of convienience, especially for remote offices where many services may be required. 5) Trust. When you're talking about letting a remote developer access your system, you generally want to only trust him with things that are directly related to him. SSL telnet only grants access to one port on one machine, and that makes it easier to control what he's got access to. You can accomplish the same thing with an additional firewall, but again, more complexity. So, IMHO, SSL telnet is a much more secure option when allowing telnet is all you want to do. Not because SSL is in any way better encryption, or even better authentication, but because there's less at stake if he breaks through, and because when it's less complex, there are fewer points of failure. But that's just my opinion, please don't crucify me. :)
As an Amazon Associate we earn from qualifying purchases.
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.