I'm confused. I keep hearing that https makes your connection to a a website "secure". What does that mean? Does it mean I can trust the site I land on? "https", or secure http, is an important part of keeping your data safe. But it's only a part. Https connections do two things: they encrypt your data so that it is nearly impossible to sniff, and they provide an opportunity for your browser to validate that the website is who you think it is. Let's look at each of those in a little more depth. Encryption is simply a way of scrambling the information that you sent to a web site, and that the web site might send back to you. In an https connection it works both ways: data that you send, say an account name and password you enter in a login form, is encrypted and sent to the remote site where it is decrypted so it can be used. Data coming back, perhaps the amount of money you have in your checking account when you visit your bank's site, is encrypted by the web server, sent to your browser, and decrypted so that your browser can display it on screen. Encryption is important because only you and the remote site can understand the data. Anyone in between ... say someone who's monitoring the information going to and from your computer ... sees only gibberish. It's an important way to keep your private data out of the hands of hackers and thieves. Another important aspect of https security, is that it can be used to validate that the site you are connecting to really is who they claim to be. The server-side of an https connection uses information, called a certificate, which can be checked, and validated, against trusted authorities. If that check fails, then your browser will warn you. Perhaps the certificate has expired (though you should check your computer's clock if you see that), or perhaps the certificate does not actually match the site you think you're visiting. Both are things that should give you pause. Now this server validation step is actually a kind of optional part of https. A server can elect to use an untrusted certificate - but every visitor to that site will get a warning that the certificate is not trusted. The data will still be encrypted. Why would a server elect to do that? Well, certification costs money. Not a lot, but it is an extra step, and not all cases really require it. Sometimes encryption is enough. Now, everything I've talked about so far is only about the technology of communicating between you and a web server. Your data is encrypted and you are talking to the web site you think you are. But it tells you nothing about whether the site you are talking to is legitimate, or whether they are keeping your data safe once it's on their server. Your data arrived there safely ... but what did they do with it after that? Any web site owner can easily, and inexpensively throw together https support. But an https connection doesn't imply that they are legitimate. You still need to know who you're talking to. Make sure that you've got the website URL correct, and that they're a legitimate business. That's what phishing scams are all about ... trying to get you to visit sites that look legitimate, but aren't. And they might even support https. (And don't forget to keep your side of the connection clean too - practice safe computing!) Related:
• Recent Comments
>Encryption is important because only you and the remote site can If someone was monitoring my computer, how could https tell my computer what password to use to encrypt and decrypt the data without the person monitoring also getting the password? Posted by: Ronny at September 9, 2005 01:05 PMBecause those passwords are never sent. Using something called public key cryptography, the sender can encrypt something with the public key that can only be decrypted by the private key. The private key is never shared, and is part of what the certification process validates. Obviously it's more complicated than that, but that's the basic idea. Posted by: Leo at September 9, 2005 01:34 PMHey Leo, good read - thanks for your time. One question though - is the URL for a https site passed in cleartext over the internet, for example would this be bad? http://www.somedomain.com/login.asp?username=bob&password=apples when a sniffer is active on the machine where the browser is launched (to visit a site say a bank site), & if the https is being used, the sniffer will not be able to catch the data supplied from the browser -correct? Posted by: santosh at June 21, 2006 11:57 AMIf the sniffer is actually running on the machine with the browser, then all bets are off. It's effectively spyware and can see everything. However a "sniffer" is typically a different computer "sniffing" the network, and https is the way to be safe. Posted by: Leo at June 21, 2006 09:05 PMthanks Leo my life just got easier can you recomend a survey web sit that pays.???? and when they say spam free is it really spam free??? Posted by: Daniel jenkins at September 12, 2007 07:53 AMI have a additional question. I understand that SSL is used to encrypt data as it is sent on a wire. But if I'm using a non-encrypted wireless access point, am I venerable to have my data sniffed between my laptop and my WAP? I understand without wireless encryption the data is sent through the airwaves in plain text. Posted by: Roland Gonzales at April 26, 2008 11:07 AMWhy don't you answer Bob's question?! I need to know! Are GET requests also encrypted? Posted by: asdfasdfas at June 13, 2008 01:10 PM-----BEGIN PGP SIGNED MESSAGE----- Bob's example goes to "http" so of course it would NOT be That same example, to a server that supports "https" would What matters is that the URL of the page getting the Leo
iD8DBQFIVUnKCMEe9B/8oqERAtd7AJ4xwKv/XGJLCt7cZVw5BsTgybqhmACfSgYT Post a comment on "Is an https connection really all that safe?":
|
Archives Advertisers |