As for viewing web sites either will do.
I would not send any sensitive data over a http connection.
Credit card #
Bank account #
When I visit a variety of different sites, sometimes I get http>website.com other times https:>website.com & sometimes I'll type https:bank name.com (which tells me can't find or can't connect. I'm wondering if it matters if it is one or the another? Does https ensure my browsing safety or the sites' safety? In simple terms I'd like to understand what the differences are to me. Are sites without https dangerous to visit? Thank you for helping me understand this.
--Submitted by Ron H.
Bob_B has provided a comprehensive link with explanations but here is another take at it:
1) HTTPS means that the communication between your computer and the website you are visiting is encrypted. It also suggests that the owner of the website passed some minimal validations by a third party and really does own the website you are visiting.
2) It is better to always use HTTPS in order to avoid snooping but it does not mean that you are really secure:
a) The website or your computer can be hacked or have viruses that will be able to "listen in" to data once it has been decrypted and read at one of the ends.
b) Some if not most enterprise devices (think of companies that offer internet and maintain it, including your workplace) can still listen to any encrypted communication including https without you noticing anything. This functionality is called deep packet inspection and gives the ability to decrypt traffic because it listens to key exchanges between your machine and website and knows what type of secret code they have agreed to use in order to encrypt data.
3) Many websites (facebook, google) have moved to HTTPS to reduce the chances of government snooping etc.
At the end , HTTPS loads a little bit more the network and your computer but provides a bit more security. it is a good idea to use it whenever you can.
Do you have a link to any page that describe this "Deep Packet Inspection" and how it breaks SSL? SSL is designed specifically to prevent that.
As the link above mentions, SSL uses a Public Key system. The user's computer encrypts using the public key, and only the computers that have the private key are capable of decoding the packets. If only the intended receiving computer has the private key, then no other computer along they way can decrypt them.
The only exchanges done at the beginning of a session are to verify that both sides are using the same encryption protocol (there are more than one.) But, knowing that information does not provide the private key. If it did, then secure communication would be impossible.
I work at a bank. We use HTTPS. You don't break it with deep packet inspection. You DECRYPT it with the certificate put on the firewall that matches the one you put on the server sending the data. The firewall receives the encrypted data, decrypts it with the provided certificate, performs a deep packet inspection, if that's what you're after, re-encrypts it and sends it on it's way.
In many cases, the decryption only happens so the data can be analyzed to make sure you're not selling your company's secrets to the highest bidder. We do LOTS of that. That's called DLP, Data Loss Prevention. Deep packet inspection is used for a different purpose. You use it to make sure that your http traffic (or whatever kind it might be) is REALLY the kind it's supposed to be.
Port 80, http, is the world's biggest hole in networks. So, you work at a company that won't let you use an instant messenger to chat with your friends. You just go find one that uses port 80. Now your company THINKS you're browsing the web when you're really chatting with someone, or giving them company secrets.
This is where deep packet inspection comes into play. Your firewall decrypts the traffic, then looks for http code. BUT, what if there's no http code in there? The firewall blocks it because it's not finding http commands, it's just finding text.
OR you decide you want your employees to be able to browse Facebook, but you DON'T want them to be able to post from work. Decrypt, look for commands to send text, drop those commands, then send the rest through. POOF! Read only access.
ALWAYS use HTTPS. Do you leave your car unlocked? Or your house when you leave? NO. Why let people steal your identity and ruin your life if you don't have to?
Friends don't let friends use HTTP!
In response to 2b, the basic idea is correct however deep packet inspection or sniffing the keys will not allow them to snoop in on the traffic. They instead basically do a men in the middle attack.
They pretend to be the target host and issue you a key they generated. They then communicate with your target host themselves and pass the information back and forth. Hence they now have the unencrypted communication. All of the corporate computers have a preinstalled certificate so your computer trusts any key they generate without any type of warning.
Most large companies however maintain a list of bank websites and do not do they attack on them and instead let the traffic pass normally. This is is for protection of both parties. There is nothing technically stopping them from doing so however.
Hard to believe but... no it is possible for the past 10 years or even more:
Go down to the "Troubleshooting" section of that page. The users must accept the Fortinet certificate for that to work. Nobody should do that, unless their employer requires it. And, if they require that, then IMHO the employee should be thinking about another place to work.
SSL is secure from Man-in-the-Middle, even Deep Inspection, unless the user accepts the bogus intermediary certificate.
Some of the terms they use are a bit bogus (like the word, "inspection" in this effect). A LOT of places want access to your SSL traffic so they can see more of the private you. Including, your passwords. If you stick these untrusted people in your SSL path, they can gather whatever information. I would never do that. If you want to "inspect" packets, just get your own device that does that. Especially if you are a business.
Here is about certificates:
I can also share a script that installs the CA certificate silently on any windows machine for most common browsers(Edge, IE, Chrome, Firefox) assuming admin rights are available.
Note that we are not talking about hacking here: those are readily available commercial products costing from 800$ to more than 100K$.
You do realize that while you are at work, you have no right to privacy, constitutional or otherwise? In the corporate world, as a condition of employment most people will sign a bunch of documents (so happy to have a job they won't even read them) and that includes Non-Disclosure Agreements as well as an Acceptable Use Policy. The later is where they tell you that the computer equipment that you use belongs to the company and not only can't you mess around with it, but that there is no privacy at all and things of that sort. They own the computer; it's their rules. Yes, I've had to search an employees computer before (as they led the employee off in handcuffs) and even to check on their browsing history.
If by "hacking" you mean "illegal", you should check with a lawyer specializing in corporate law and bring all the documents that you signed.
Currently commercial products that I am aware of (Barracuda and Fortigate) do not allow for stealth snooping but since I actively manage a few of those I know that:
-- the inspection can be done on the fly (packet size) or can use a buffering technique (file size)
-- in all scenarios the original content or part of it is temporarily stored on the NGF unit
-- in al scenarios the keys are linked and uniquely associated with each ssl session on the unit
-- nothing except public opinion stops the NGF from sending the original packet or file after decrypting a copy of it in the background thus leaving no traces of snooping
-- Fortigate unit has now a new mode capable of inspecting, analysing and logging all network traffic without the ability to interfere into it (no defence mode) but being totally invisible to a user with a full capacity of SSL inspection. See here: https://www.fortinet.com/offers/cyber-threat-assessment.html Yes, it does not show, by default, individual packets and does not log data streams but who says that it is impossible or hard to do?
BTW "large companies" identifier is misleading... all of the NGF manufacturers sell units for all sizes of networks from 10 workers to thousands and even more and most do inspect all encrypted traffic no matter the source including banking but do not normally store or log real data sent/received by the user.
HTTPS is there for secure encrypted transmission between computer and web site. Without it, no encryption. Beyond payment of money, a lot of other web site dialog needs to be encrypted, too. Just think, if you had unencrypted webmail, somebody could snoop and steal your email address and password. I mention this, because my ISP email that I want to escape from, charter.net, displays only HTTP for one critical dialog, and only under certain circumstances. Yet they refuse to acknowledge the problem. So when I log into Charter's web mail, I do it in such a way that it is HTTPS all the way. No excuse for this.
I have gone around and around with Spectrum/Charter techs for the last two months about the fact that http://www.spectrum.net is insecure. They just don't get it that if their web site flips back and forth between http:// and https:// , which their web site does, it is inherently insecure. Today, I got a call from a Spectrum tech, who claimed that everything was A-OK. Well it's not. Their web site should be https all the way, like Google's and other major web sites!
One thing that hasn't been mentioned. HTTPS also protects against the man-in-the-middle attacks.
You're at a coffee shop that provides free Wi-Fi. You look at the list of Wi-Fi signals available, and in addition to nearby businesses you see "CoffeeShopWiFi" and "CoffeeShopHighSpeed." You might choose "CoffeeShopHighSpeed," hoping to get a better connection. What you don't realize is that "CoffeeShopHighSpeed" is actually another customer with his own Wi-Fi device, trying to get people to go through him to get to the Internet.
When you use your browser to look at a website, his computer pretends to be that website and captures the request and then sends it on to the real website. When the website responds, the bad guy's computer sends that back to you. Meanwhile, he is recording all of this traffic in both directions.
If it is an insecure HTTP connection, then he can read everything being sent back and forth. But, if it is HTTPS, then all he sees is gibberish.
But, what if he pretends to be your bank website?
One of the things that makes HTTPS powerful is that it is very tightly tied to the website/IP address of the organization that took out the certificate. Therefore, his fake website will fail that test. Your machine will refuse to connect to his fake website, because the IP address won't match. And, if he sends the request on to the real website, then everything after that will be encrypted and he will be unable to decipher it.
From your point of view, all of this happens automagically, as long as you're connecting to the HTTPS version of the website.
The answer(s) to your question is very complicated. As other people had said, http is sending either question of respond to/from a website is in clear text. Your ISP or provider down the line can see whatever you are sending and receiving. HTTPS on the other hand, the message (either sending or receiving) is encrypted and your ISP or service provider downstream from your ISP cannot read the CONTENT of your message. But your ISP can see the destination and origin of your traffic and unless you take some technical precaution (eg: Tor browser, VPN). HTTPS doesn't guarantee you safe browsing, rather it give encrypted browsing so nobody can see what you are sending and receiving. I'm not an expert but I'm trying to learn ,more about security everyday. And this is what I've found so far.
HTTPS is encrypted prior to transmission. HTTP is not. There are other minor differences, like site authentication and the logical port number used, but that is the key difference.
HTTP can be intercepted and read by anyone with a packet sniffer -- which is easily available as freeware software. You have to be MUCH more sophisticated to read anything transmitted with HTTPS. If you don't want anyone to get your account names, passwords, and/or other data, don't send it over an unencrypted connection,
When everything works correctly, https enables secure socket layer (or more accurately Transport Layer Security). Though various mechanisms are involved (Public Key Infrastructure for authentication and key exchange, symmetric encryption for content encryption, digital signature to verify message integrity), the bottom line is getting your messages to the host site and their messages to you without an outside observer knowing the content. For practical purposes, when your target site (say a bank) is using strong cryptographic algorithms and a known-good Certificate Authority Extended Validation root, then you can be pretty sure no one is going to intercept your traffic.
There are lots of exploits that can break cryptography, but if both ends, the network, and you (or your company) are diligent to patch their software regularly and follow good practices (like not opening questionable emails or browsing questionable sites), you can be fairly confident you will be safe. Unfortunately, this is not always the case (cff. the recent Equifax breach), but we do the best we can, right? A recent webinar stated that 70% of breaches are caused by the things I just mentioned, not by cryptography cracked by the NSA or state-sponsored actors. Hopefully they're more interested in Donald Trump and Hillary Clinton than you or I, anyway.
Ron, when the Internet (not the WWW) was created, there was no "security" designed in because all of the routers belonged to the government-industrial complex. Back in the 1970's the average person was NOT on the Internet unless they had reasons to be there and UNIX or Mainframe computers or teletypes. It wasn't until the World Wide Web was created in the 1990's after desktop computers came about that "people" really came into play.
After the WWW came out, certain transactions needed to be secure. What most people don't realize is that what comes and goes from and to their computer screen goes through a series of "hops" (you can see these via the Tracert/Traceroute utility). Anyone at those routers could "see" every bit of data that goes through and there were also other ways to tap into a "conversation". That is why HTTPS (S = 'Secure') was created so data sent from one computer to a server or the other way around would be encrypted using a system of encryption keys.
It started out that the HTTPS: was only used to encrypt the logon, but today, by nature of the data passing through, many sites only use HTTPS. By the way, HTTP is usually on a "port" number of 80 while HTTPS runs on 443 (or other ports like 8443).
If you are just browsing stuff, you can get by with port 80 or HTTP. However, if the data is critical, and the website supports it, you should use HTTPS. Not all sites support that especially with the same web pages. That is, a web page may be HTTP only or HTTPS only or both.
In some cases, you will start with HTTP and the website will switch you to HTTPS as part of their design. Firefox (web browser) usually warns me if I am putting data out onto an insecure website and I can decide what I want to do. Especially, if you are going to send a secure login and password.
The REAL problem, with all of this, is that NONE of it iis presented, in a form, which NORMAL human beings can understand.
EVERYTHING is presented ONLY for the understanding of computer programmers.
That, and those, with a Ph.d, in computer technology.
For the other 99.999% of the world, this information is use-LESS, since we do not "speak" this "language".
As for "data breaches", these are as "old" as this tech, itself.
Simple fact is that NONE of this tech was, ever, designed, for normal human beings.
It was, all, completely, and totally, designed, ONLY for computer programmers, and Ph.d's, in computer technology.
Until this CHANGES, such articles are use-LESS, to 99.999% of the world.
Luckily, the fact that you don't understand it, doesn't mean that the member (Ron. H.) that asked the question in the top post doesn't understand it. Until further notice, I even assume he does.
In the CNET community mail yesterday, which I assume triggered your post here, forum manager Lee Koo summarizes the answers as follows:
"As for the difference between HTTP and HTTPS, as you read through your fellow members' answers, we all can agree that the additional "S" indicates a connection that is secure, in which the data/files passed over the internet between your browser and the web site are encrypted -- meaning people who are up to no good and want to read and steal that data can't see it. Whereas with HTTP, that data can be read. So when does it matter if it's an HTTP or HTTPS website? If you are just surfing the web, reading sites without logging in or doing transactions, that should be fine. But if you are interacting with sites by logging in or providing any personal information such as passwords or credit card numbers, HTTPS is a must so that your personal data will be encrypted."
What of this explanation do you think cannot be understood by 99,999 out of 100.000 people, that is by only 8 people in the whole town of San Francisco (that has 870,000 inhabitants), that aren't programmer or have a Ph.D in computer programming?
I assume that at least 50% of the 'normal' people know the meaning of the words data, website, surfing the web, sites, logging in, transactions, password, all of which is common current USA English. The only more or less specialised term (encrypted) is explained,
In fact, Lee Koo, who wrote this, is not a programmer, nor a Ph.d in computer technology, and I'm sure he understands what he writes. So there are only 7 other of those people in San Francisco? Do you really believe that? I don't.
Post was last edited on September 23, 2017 12:11 PM PDT
Here are some steps I take to improve the security of web sites:
1 - I install the HTTPS Everywhere extension from the Electronic Frontier Foundation (works with Firefox, Chrome, and Opera):
2 - Before actually entering any personal information (like login credentials or a credit card number) on an HTTPS: web site, I test it with the Qualys SSL Server Test:
I want an "A" or "A+" rating on every HTTPS: web site I use. If it does not get a good rating, I send the link with the poor report from the Qualys SSL test web site to the subject web site's admins and ask for the problem to be resolved.
I also, of course, keep my OS and browsers OS and other installed apps up-to-date. I limit the number of apps (and browser extensions) installed. I do not readily trust my Windows computers because the Windows update process has so many problems.
It's not clear to me how to secure the Safari browser; HTTPS Everywhere does not support Safari.
I do not use any financial institution's app because I cannot test the SSL certificates used, or the security configuration of the app itself.
I'd love to learn how to test these apps, and how to interpret the test results.
-- Bob Stromberg
I was 'stung' (and rather badly) when I fell for a bogus Paypal 'security alert' requesting account information to update my file. The key thing that I looked for was the "HTTPS" which was even addressed in the bogus email I had received... I.E. "Make sure to only log in to a SECURE site, etc."
Only after giving up everything they asked for including SS#, etc, I discovered that the whole thing was bogus.
After contacting Paypal directly I was told "Do NOT answer that email!"
Too late. "HTTPS" actually means very little in today's world of cyber crime. Someone setting up a bogus phishing program can call themselves anything they want and can list their URL anyway they want. I've even received bogus phishing emails from 'myself' when my email address found it's way to someone else's list that was hacked. A common ploy is to impersonate someone's known contacts.
Goomba - if you click on a link to a malicious site, you'll just have an encrypted connection to the bad site. It's harder to detect bogus emails now, but watch for unsolicited mail, mail from a domain you don't recognize or that is slightly odd (like paypal0.com or when an IRS email comes from treasury.gov.ca ). In the case of email which appears to be from a known source, look out for unexpected topics (e.g. - you wouldn't expect an off-color message from your Christian friend or an invitation to a financial meeting from your mother-in-law). I have even been taken in once in the last year, so don't feel bad. However, if that happens, try to have the Best Buy folks or someone knowledgeable verify your system is clean. In my case, nothing was found, but my company (in financial services) decided it was best to wipe and reimage the laptop. Oh yes, one additional sign (but not perfect) is the logo displayed when the encrypted connection is established. For a big company, there should be a logo. If you have any doubts, contact the source and verify.
For Hats and Cats - Kudos for the steps you are taking. I don't have a Mac, but on my iPhone, there is a lock in the search box when https is used. I don't know of a practical way to verify that a connection is encrypted short of doing a packet trace and watching it happen. I do that for a living, but I don't do it on my home devices. Pragmatically, you need to decide if you trust the company. As we see from Equifax breach, not all companies are trustworthy.
One way to avoid this is NEVER trust a link found in an email. If its PAYPAL, then go to the Paypal site. You can PRINT that email as a reminder to do so. Unfortunately, security is "supposed" to be inconvenient. Especially for the bad guy. Norton Security is supposed to help with bad links in emails but I wouldn't know because I don't click in emails.
As the CEO of Anthem once said, "We were breached because security is inconvenient".
A secure site in and of itself is only half the story - the other half is the security certificate used to secure the connection must actually belongs to the entity that is advertised. When you point your browser at a https: site, an encrypted channel is setup using a designated certificate. Good browsers actually display the name of the company on the certificate along with warnings if the CA (certificate authority) is not trusted. They also present a visual indication (e.g. green color in address bar) that an EV (Extended Validation) certificate is being used. The latter makes it more unlikely that anyone could have obtained a valid certificate under false pretenses. These should be checked. The other thing is to use an email client that lets you determine the URL that is in an email before you click on it. For example, Outlook lets you hover over a link.
Sublime suburban chariot
High on style and technology, the 2019 Volvo XC90 is an incredibly satisfying everyday crossover.