Http vs. Https and Telnet vs Secureshell

Maybe you've noticed that mostly all the websites you visit show a little lock symbol next to them in your internet browser's address bar and begin with "https"(the "s" standing for "secure"). It wasn't always this way. It wasn't too long ago that many sites were ordinary http (non-secure) sites. According to Stat Operator , a global web statistics organization, 57.1% of the most popular 137,971 websites are now "https". In fact, popular search engines like Google have been known to punish websites who did not convert over to the secure format by booting them from their search results. Most sites will redirect automatically to their https site even if you only typed it in with http. It's an understandable move, as Google naturally wants to lessen the risk of hacking for their end users and for those websites/companies that make up their results. You might be wondering "What's the difference and what makes one secure and the other not?"


To best understand this, we need to hop into Wireshark, a program that is in every Network and Cybersecurity Technician's toolbox without question. Wireshark is a free packet analyzer application and is available for Windows, Mac, and Linux. While it is often used to diagnose network traffic issues by administrators, it can just as well be used for malicious purposes by those looking to steal sensitive information. It will give you a nitty-gritty, sometimes brain-overloading display of network traffic and everything in those internet packets that allows them to route from their source to the destination, wherever that might be. Wireshark takes some time to start to understand. It's best not to let it intimidate you right off the bat with all the details it shows you. It will take time to understand the relevancy of some of the data that may seem like minutia at first.



Just know for now that in Wireshark, you can capture traffic and easily see any information that the visitor of a non-secure (http) website entered on there, be it the username field, the password field, the search field, etc. It doesn't matter! That is what 100% unencrypted internet traffic looks like. You can now see why this is so risky.

To test this out yourself, you can hop onto Aliweb, which is said to be the oldest search engine ever and amazingly enough is still hosted and online and non-secure in all it's ..uhh..."glory".... http://www.aliweb.com/ .





Try typing into the search field and see if you can locate the packet in Wireshark that contains what you typed in there. In the screenshot pictured above, I am looking for the word "search" because the information I typed was into a search field on the unsecured website. But this could just as well be a search for any of the following keywords: login, pass, password, username, email. Anything that we get a hit on will show us what was entered in it's field back on the non-secure website. Since it's becoming increasingly difficult to find a non-secure http site that contains login fields (and thank goodness), the above scenario is a good comparison.

This of course, is in contrast to any information you would enter on an https site. With encryption now occurring on the secure site ( www.google.com for instance ), that turns any of your entered information into nothing but jumbled gobbledygook to anyone trying to snoop in and view it on a packet analyzer like Wireshark.

The relationship between http and https can be directly tied to the one between Telnet and SecureShell (SSH). Telnet is an administrative terminal session that you create inside of a command prompt window to be able to configure the device on the other end, be it a router, switch, or firewall. A password is entered, disguised by asterisks, but don't let that fool you. We face the exact same vulnerability here and this too will show up in good ol cleartext (immediately understandable, unencrypted data). Just as HTTPS has resolved this issue for HTTP, Telnet has since been replaced by SSH. SSH acts pretty much identical on the surface to Telnet aside from the initial configuration, which presents several options for RSA Key length, etc.

Telnet login screen examples (non-secure, should not be used)




See below, encryption options when initially configuring a SecureShell (SSH) terminal line.