SSL and compromised networks?
March 22, 2009 2:01 PM Subscribe
Does SSL protect information even if the wi-fi connection is unsecured?
Say a person is using an available wi-fi network, the source of which he doesn't know. It could be a generous neighbor, or a honeypot. If the person checks his email and his bank accounts, does it matter that the URLs begin with https://?
If the ethics of this question are problematic, consider the hypothetical case of "duplicated" public wi-fi hotspots, in which a hacker creates a network with a duplicate SSID.
Say a person is using an available wi-fi network, the source of which he doesn't know. It could be a generous neighbor, or a honeypot. If the person checks his email and his bank accounts, does it matter that the URLs begin with https://?
If the ethics of this question are problematic, consider the hypothetical case of "duplicated" public wi-fi hotspots, in which a hacker creates a network with a duplicate SSID.
Does SSL protect information even if the wi-fi connection is unsecured?
Yes it does.
Of course, the user needs to type in the URL with the prefix https:// and without any typos or mistakes.
posted by Mike1024 at 2:09 PM on March 22, 2009
Yes it does.
Of course, the user needs to type in the URL with the prefix https:// and without any typos or mistakes.
posted by Mike1024 at 2:09 PM on March 22, 2009
In the abstract, no borrowed network connection is safe, as SSL is generally vulnerable to a DNS man in the middle attack, if the attacker is able to obtain a fraudulent certificate.
In pragmatic reality, you'd probably have to have a pretty elaborate setup in order to do it. It would take some serious preparation to get the certificate, hijack DNS to your domain, etc.
In other words, it's probably "safe enough", unless you have some very powerful enemies or some very sensitive data. The three hundred bucks in your savings account probably isn't enough motivation.
posted by jenkinsEar at 2:11 PM on March 22, 2009
In pragmatic reality, you'd probably have to have a pretty elaborate setup in order to do it. It would take some serious preparation to get the certificate, hijack DNS to your domain, etc.
In other words, it's probably "safe enough", unless you have some very powerful enemies or some very sensitive data. The three hundred bucks in your savings account probably isn't enough motivation.
posted by jenkinsEar at 2:11 PM on March 22, 2009
No.
If you're trusting a network connection, you're trusting that it routes your traffic to the location that you want it routed.
For example, you're trusting that the network really does route your requests for megabank.com to megabank.com, rather than to its own server that looks like megabank.com.
And when you ask Verisign to confirm that the SSL certificate that you just got back from something claiming to be megabank.com really is from megabank.com, you're trusting that the network really does route your query to Verisign, rather than to its own server that looks like Verisign and simply replies "Sure, that's megabank.com".
posted by Flunkie at 2:11 PM on March 22, 2009
If you're trusting a network connection, you're trusting that it routes your traffic to the location that you want it routed.
For example, you're trusting that the network really does route your requests for megabank.com to megabank.com, rather than to its own server that looks like megabank.com.
And when you ask Verisign to confirm that the SSL certificate that you just got back from something claiming to be megabank.com really is from megabank.com, you're trusting that the network really does route your query to Verisign, rather than to its own server that looks like Verisign and simply replies "Sure, that's megabank.com".
posted by Flunkie at 2:11 PM on March 22, 2009
Does SSL protect information even if the wi-fi connection is unsecured?
Yes. Traffic using https is encrypted at the client (your browser), and travels encrypted over the network to the server, where it is decrypted. Realistic worst-case: someone can see that you're transferring data to/from a specific address by looking at the logs. I wouldn't transfer military secrets, but your banking is fine.
Look at it this way- it's way more secure than visiting an ATM, which also occurs in a "public" place.
posted by mkultra at 2:14 PM on March 22, 2009
Yes. Traffic using https is encrypted at the client (your browser), and travels encrypted over the network to the server, where it is decrypted. Realistic worst-case: someone can see that you're transferring data to/from a specific address by looking at the logs. I wouldn't transfer military secrets, but your banking is fine.
Look at it this way- it's way more secure than visiting an ATM, which also occurs in a "public" place.
posted by mkultra at 2:14 PM on March 22, 2009
And when you ask Verisign to confirm that the SSL certificate...you're trusting that the network really does route your query to Verisign, rather than to its own server that looks like Verisign and simply replies "Sure, that's megabank.com"
SSL doesn't work that way. You don't need to connect to Verisign to confirm a cert. Your browser already has the verisign, and other companies, certs on your computer. SSL just confirms that the cert the remote computer has is signed by one of the certs on your box.
posted by jsonic at 2:17 PM on March 22, 2009
SSL doesn't work that way. You don't need to connect to Verisign to confirm a cert. Your browser already has the verisign, and other companies, certs on your computer. SSL just confirms that the cert the remote computer has is signed by one of the certs on your box.
posted by jsonic at 2:17 PM on March 22, 2009
It's still possible to hijack ssl connections although it's a decent technical hurdle that most of the time you don't need to worry about it. If you are the type to worry about it and you use Firefox you can install the perspectives add in which will check notary servers and attempt to validate the certificates being served up.
posted by iamabot at 2:18 PM on March 22, 2009 [1 favorite]
posted by iamabot at 2:18 PM on March 22, 2009 [1 favorite]
If you're trusting a network connection, you're trusting that it routes your traffic to the location that you want it routed.
... and presents you with site that looks and appears to work like whatever site you're trying to visit. Because you wouldn't be suspicious at all when megabank.com doesn't look quite right, would you?
posted by mkultra at 2:19 PM on March 22, 2009
... and presents you with site that looks and appears to work like whatever site you're trying to visit. Because you wouldn't be suspicious at all when megabank.com doesn't look quite right, would you?
posted by mkultra at 2:19 PM on March 22, 2009
In theory, no - an untrusted network can intercept your SSL traffic using say, DNS tricks, and using various recent tricks, present a fake site with a genuine SSL certificate. You check, it looks genuine - but it isn't. This is called a Man in the Middle attack.
In practise though, yes, you're fine. You use public networks every day, when you route over the various ISPs that route your connection to your bank. The chances that some random neighbour is going to have an open access point, while also running an elaborate sting operation to intercept your particular bank site is pretty remote.
In the case of public wifi points in say, cafes - probably best not to do your banking over that kind of access. Even if you're actually going through the cafe's access point, it's pretty straightforward for the guy next to you to ARP spoof your traffic, and if he's going to that level of effort, he may well be trying to intercept your passwords etc. Plus there's always simple shoulder surfing. The odds that you'll get attacked are still pretty low, and the odds of him successfully spoofing SSL connections are lower still, but they're definitely not zero. If you're using a shared machine in a netcafe, there could just as easily be a keylogger and screengrabber.
Personally, I wouldn't take the risk in those circumstances, but then I'm pretty paranoid about security risks. Plenty of others do. Entirely up to you.
posted by ArkhanJG at 2:34 PM on March 22, 2009
In practise though, yes, you're fine. You use public networks every day, when you route over the various ISPs that route your connection to your bank. The chances that some random neighbour is going to have an open access point, while also running an elaborate sting operation to intercept your particular bank site is pretty remote.
In the case of public wifi points in say, cafes - probably best not to do your banking over that kind of access. Even if you're actually going through the cafe's access point, it's pretty straightforward for the guy next to you to ARP spoof your traffic, and if he's going to that level of effort, he may well be trying to intercept your passwords etc. Plus there's always simple shoulder surfing. The odds that you'll get attacked are still pretty low, and the odds of him successfully spoofing SSL connections are lower still, but they're definitely not zero. If you're using a shared machine in a netcafe, there could just as easily be a keylogger and screengrabber.
Personally, I wouldn't take the risk in those circumstances, but then I'm pretty paranoid about security risks. Plenty of others do. Entirely up to you.
posted by ArkhanJG at 2:34 PM on March 22, 2009
SSL is equally effective on a wired network connection that you do not fully trust every step (often about a dozen) between you and your bank (not just their intentions but also trust them to not get hacked) as it is on an unsecured wireless network.
So, basically the answer is yes, it's quite difficult to really mess with your data if you're using SSL but not impossible (wireless or wired doesn't matter).
posted by aubilenon at 2:35 PM on March 22, 2009
So, basically the answer is yes, it's quite difficult to really mess with your data if you're using SSL but not impossible (wireless or wired doesn't matter).
posted by aubilenon at 2:35 PM on March 22, 2009
Well, SSL will encrypt the HTTP connection in that case. But if the wifi connection is completely unsecured, someone who is watching constantly may be able to catch the key exchange between your browser and the server, which would allow them to decrypt the message (and hence get hold of your bank information, the passwords you typed in, and the answers to any security questions you answered.)
I'm not a cryptography expert but I'm pretty sure that the people here who are claiming it's safe - particularly mkultra's claim that this would be safer than using an ATM in a public place - are incorrect. jsonic is correct that Verisign is not contacted in the course of establishing or using an SSL connection; all that happens is that when the server sends its key (and for other messages), your browser is able to verify that the message was sent by a server that has a purchased Verisign certificate on it as opposed to a self-signed certificate. The most Verisign can ever do is revoke a server certificate, after the fact, once they receive and confirm reports that something shady is being done through that server (and hence force them to buy another Verisign certificate... nice little racket, huh?)
Also, remember that the sort of monitoring activity that would result in an attack on you does not by any means need to be done by someone who is physically within range of the same wifi network. Half of the other people accessing the same wifi network - even at a hotel with a secured public wifi network where you need to obtain an SSID key from the front desk - could have viruses on their laptops so that they're being used as zombies searching for vulnerable traffic by someone in Estonia or Guangdong, China, for example. I have witnessed what appear to be viruses trying to log on to my home network with random faked host names and MAC addresses, because I know all of my neighbors and I'm pretty certain none of them have the skills to conduct such attacks themselves. (Including their kids.)
posted by XMLicious at 2:46 PM on March 22, 2009
I'm not a cryptography expert but I'm pretty sure that the people here who are claiming it's safe - particularly mkultra's claim that this would be safer than using an ATM in a public place - are incorrect. jsonic is correct that Verisign is not contacted in the course of establishing or using an SSL connection; all that happens is that when the server sends its key (and for other messages), your browser is able to verify that the message was sent by a server that has a purchased Verisign certificate on it as opposed to a self-signed certificate. The most Verisign can ever do is revoke a server certificate, after the fact, once they receive and confirm reports that something shady is being done through that server (and hence force them to buy another Verisign certificate... nice little racket, huh?)
Also, remember that the sort of monitoring activity that would result in an attack on you does not by any means need to be done by someone who is physically within range of the same wifi network. Half of the other people accessing the same wifi network - even at a hotel with a secured public wifi network where you need to obtain an SSID key from the front desk - could have viruses on their laptops so that they're being used as zombies searching for vulnerable traffic by someone in Estonia or Guangdong, China, for example. I have witnessed what appear to be viruses trying to log on to my home network with random faked host names and MAC addresses, because I know all of my neighbors and I'm pretty certain none of them have the skills to conduct such attacks themselves. (Including their kids.)
posted by XMLicious at 2:46 PM on March 22, 2009
someone who is watching constantly may be able to catch the key exchange between your browser and the server, which would allow them to decrypt the message
I don't think so. A man-in-the-middle attack lets an attacker pretend to be the server with whom you're communicating, but a casual observer cannot decrypt SSL traffic between two other parties, even if it observes the key exchange. Exchange of the symmetric encryption key is itself encrypted with (slower) public/private key encryption.
In addition to ArkhanJG's link, there are lots of ways in which SSL is correct in theory, but popular browsers screw up the implementation. For example, a malicious proxy can embed unsecure HTTP frames in a secure HTTPS frame, and your browser will still happily show the SSL lock and not tell you about it. These embedded frames can execute scripts in the context of the secure page, allowing for all sorts of bad things to occur.
posted by qxntpqbbbqxl at 3:05 PM on March 22, 2009
I don't think so. A man-in-the-middle attack lets an attacker pretend to be the server with whom you're communicating, but a casual observer cannot decrypt SSL traffic between two other parties, even if it observes the key exchange. Exchange of the symmetric encryption key is itself encrypted with (slower) public/private key encryption.
In addition to ArkhanJG's link, there are lots of ways in which SSL is correct in theory, but popular browsers screw up the implementation. For example, a malicious proxy can embed unsecure HTTP frames in a secure HTTPS frame, and your browser will still happily show the SSL lock and not tell you about it. These embedded frames can execute scripts in the context of the secure page, allowing for all sorts of bad things to occur.
posted by qxntpqbbbqxl at 3:05 PM on March 22, 2009
Response by poster: Thanks, all, for the answers so far. The general verdict seems to be at a pragmatic level, it can be assumed to be safe, as long as the user is moderately aware of what he's doing.
I probably should have said an "untrusted" network, and not simply an unsecured network. I'm sorry if I'm getting the terminology wrong, but my question doesn't concern the public network at the library or Starbuck's, but rather piggybacked networks or possibly fraudulent networks that appear to be the Starbuck's network.
posted by Busoni at 3:19 PM on March 22, 2009
I probably should have said an "untrusted" network, and not simply an unsecured network. I'm sorry if I'm getting the terminology wrong, but my question doesn't concern the public network at the library or Starbuck's, but rather piggybacked networks or possibly fraudulent networks that appear to be the Starbuck's network.
posted by Busoni at 3:19 PM on March 22, 2009
What you're asking about is whether SSL protects against man-in-the-middle attacks. The quick answer is "Yes", and in fact that's a major thing that SSL was designed to secure you with. One key purpose of SSL is to let you talk to your bank from your laptop without having to trust the network inbetween. The longer answer is "no, but you're probably OK". Because while SSL is designed to safeguard against MITM, there are some implementation and design flaws that mean in theory it's attackable. Both SSL itself and the browser implementation around it. In practice you're unlikely to find anyone actually actively exploiting SSL in these ways, so if you're just stealing a random open WiFi link you're probably OK.
posted by Nelson at 3:21 PM on March 22, 2009
posted by Nelson at 3:21 PM on March 22, 2009
The encryption aspect of an SSL connection protects against 3rd parties from reading the contents of your communications with a secure web site. This should protect you against a wireless access point that is trying to snoop on your traffic, and against other users of the same access point who might be trying to do that. Or for that matter, the same problem at any one of the other places this could happen between your computer and the secure site.
The authentication aspect of SSL is intended to ensure that you really are connecting to the site you asked for, to prevent man in the middle attacks. It works by the real site having a digital certificate signed by a certificate authority that your browser trusts. It is easy for a rogue network operator to redirect your traffic to a fake site, the hard part is supposed to be faking a certificate that your browser will accept.
The easiest way to do it would be to send a fake certificate and expect that a fairly high percentage of people will just click 'OK' to ignore the security warning that comes up. This was made a lot harder to do in newer versions of Firefox (for example) specifically to make this kind of security problem much harder to ignore.
Another easy way to do it is to get a real certificate issued by a genuine certificate authority. I remember the first time I had to get one of these, the extensive checking that was done to make sure we really were the organization we claimed to be. Lately it seems to be far too easy. As in the security of SSL now depends on bad guys being unable to find any CA willing to take their money, as there didn't seem to be much other checking going on any more.
posted by FishBike at 4:57 PM on March 22, 2009
The authentication aspect of SSL is intended to ensure that you really are connecting to the site you asked for, to prevent man in the middle attacks. It works by the real site having a digital certificate signed by a certificate authority that your browser trusts. It is easy for a rogue network operator to redirect your traffic to a fake site, the hard part is supposed to be faking a certificate that your browser will accept.
The easiest way to do it would be to send a fake certificate and expect that a fairly high percentage of people will just click 'OK' to ignore the security warning that comes up. This was made a lot harder to do in newer versions of Firefox (for example) specifically to make this kind of security problem much harder to ignore.
Another easy way to do it is to get a real certificate issued by a genuine certificate authority. I remember the first time I had to get one of these, the extensive checking that was done to make sure we really were the organization we claimed to be. Lately it seems to be far too easy. As in the security of SSL now depends on bad guys being unable to find any CA willing to take their money, as there didn't seem to be much other checking going on any more.
posted by FishBike at 4:57 PM on March 22, 2009
In the event of a Man-in-the-middle attack, you will get an error message saying that a certificate is untrusted or unverified. If you are doing something that involves sensitive data, and you get that message, stop.
You could be on a wired broadband connection, but depending on the way the network is configured, your traffic might be able to be sniffed, and possibly hijacked. The cert. system is pretty good, just take warnings very seriously.
There's a history of security flaws in IE, so don't use it.
Be a little bit paranoid, read your browser messages, and keep your Operating System patched. (i.e., windows updates)
posted by theora55 at 5:22 PM on March 22, 2009
You could be on a wired broadband connection, but depending on the way the network is configured, your traffic might be able to be sniffed, and possibly hijacked. The cert. system is pretty good, just take warnings very seriously.
There's a history of security flaws in IE, so don't use it.
Be a little bit paranoid, read your browser messages, and keep your Operating System patched. (i.e., windows updates)
posted by theora55 at 5:22 PM on March 22, 2009
AAAAARGH. I totally thought I had a handle on that. But qxntpqbbbqxl was right to correct me: I did not properly understand the Diffie-Hellman exchange until I re-read it just now. (So thank you qxntpqbbbqxl.)
Still, it's no excuse for anyone to stop being paranoid.
posted by XMLicious at 5:30 PM on March 22, 2009
Still, it's no excuse for anyone to stop being paranoid.
posted by XMLicious at 5:30 PM on March 22, 2009
The biggest practical weakness with SSL is the large number of Trusted Root certs that many people surf with. Take a look in your internet options for certificates sometime. Anyone in that list can sign a cert for any site you visit. Here's the start of the latest default list in Firefox, the "secure" browser,
TURKTRUST
ABA.ECOM
AddTrust AB
...
AOL Time Warner Root Certificate Authority
Yeah, those totally sound like companies I can trust to confirm my bank's identity.
posted by nomisxid at 6:17 PM on March 22, 2009
TURKTRUST
ABA.ECOM
AddTrust AB
...
AOL Time Warner Root Certificate Authority
Yeah, those totally sound like companies I can trust to confirm my bank's identity.
posted by nomisxid at 6:17 PM on March 22, 2009
Whoever said this:
And when you ask Verisign to confirm that the SSL certificate that you just got back from something claiming to be megabank.com really is from megabank.com, you're trusting that the network really does route your query to Verisign, rather than to its own server that looks like Verisign and simply replies "Sure, that's megabank.com".
Is totally wrong. SSL is not vulnerable to layer 2 or layer 3 attacks. SSL vulnerabilities come in various flavors (compromised certificate, attack of initial non-encrypted HTTP sessions to insert a proxy, etc.) but the network layer is not one of them.
The problem with using an open wifi is not that you will lose your bank credentials if you access https://www.bankofamerica.com from an open wifi network, the problem is that your computer makes a ton of non-encrypted connections when it connects to a network that leave it open to compromise [mail, mac users -- the dashboard applets are all safari and subject to http/tcp intercept attacks, etc. etc.]. This is a significant problem and all of the OS vendors have been very sloppy about them. No connection that is established on connection to a new network (interface flap, etc.) should not be SSLified -or- the only traffic that is allowed is traffic for a VPN client [and that traffic thereafter].
posted by rr at 6:56 PM on March 22, 2009
And when you ask Verisign to confirm that the SSL certificate that you just got back from something claiming to be megabank.com really is from megabank.com, you're trusting that the network really does route your query to Verisign, rather than to its own server that looks like Verisign and simply replies "Sure, that's megabank.com".
Is totally wrong. SSL is not vulnerable to layer 2 or layer 3 attacks. SSL vulnerabilities come in various flavors (compromised certificate, attack of initial non-encrypted HTTP sessions to insert a proxy, etc.) but the network layer is not one of them.
The problem with using an open wifi is not that you will lose your bank credentials if you access https://www.bankofamerica.com from an open wifi network, the problem is that your computer makes a ton of non-encrypted connections when it connects to a network that leave it open to compromise [mail, mac users -- the dashboard applets are all safari and subject to http/tcp intercept attacks, etc. etc.]. This is a significant problem and all of the OS vendors have been very sloppy about them. No connection that is established on connection to a new network (interface flap, etc.) should not be SSLified -or- the only traffic that is allowed is traffic for a VPN client [and that traffic thereafter].
posted by rr at 6:56 PM on March 22, 2009
Lets look at your specific example; using the net at starbucks, but someone is sat in a car outside (or even inside) broadcasting a fake starbucks ID'd wifi access point. You connect to his fake point, instead of starbuck's one. Or, if you're using a non-passworded open access point, they can just pull in everything sent over wireless anyway by listening in even without a fake access point.
Now, we can assume that he's doing this in the first place to snoop on people's web traffic. He will receive everything that's sent in the clear. Take gmail for example - by default, if you go to the unencrypted page, it will switch to https for the login and password, but the rest of your email browsing will be sent in the clear, and the snooper will get the lot. Quite a lot of sites still don't even default to https for login.
Lots of websites do this. In gmail's specific case, you can change an option in the settings so it defaults to using https always, and you can also manually go to the https site first.
If you're checking email via POP or IMAP, connecting unencrypted is usually still the default for many providers, you have to manually change it to using a secure SSL channel - and anything sent unencrypted is easily snooped. Equally, many sites still send information in the clear, even logins.
This is what he'll be trying to get - it's low hanging fruit, and there's a lot of it. You can steal identities, compromise email accounts (and then use those to get access to lots of other websites), get personal info of all sorts, that's just sent out entirely in the clear.
SSL sites are pretty secure. The tech for the encryption itself is still safe; if you connect to the real site, with a real certificate, any snooper will simply not be able to listen in on that traffic, it's what it's designed to do, and there's no practical way round it for a hacker.
The exploits for SSL rely on social engineering - either putting up a fake site and hoping people ignore the bad certificate warnings, or exploiting weaknesses in our trust for the many, many certificate authorities, and exploiting a weakness in the way some are issued to get genuine certificates you're not supposed to have so the fake site looks genuine. Or hell, just redirecting you to the unencrypted site, so you end up using the unsecured site instead of the secured one you thought you were going to.
The odds that someone is going to go to that level of sneakiness, and then spend their time hanging around a starbucks is simply not very likely at all. Not when he get so much easily, just by going for the the low-hanging unencrypted fruit.
I mean, he could sit there and insert malware by replacing the adverts, turning every unencrypted site you go to into a drive-by download site - use that to install a keylogger, and he gets everything you type, whether it's in an encrypted site or not.
If you pay attention to bad certificates, keep your system patched and free from malware, have a good firewall and up to date antivirus, and only visit SSL sites, yes, you're safe enough as a general practical measure, even if someone is listening in. Skilled hackers are going to be off writing the next conficker or showing off their brilliant browser exploit at a hacker conference, not hanging around starbucks trying to spoof bankofamerica.com.
That said - I have a linux box at home which I use for online banking. I don't do it on public networks, I don't even do it on windows at home; but as I said, I'm more paranoid with online security than most. I don't let my credit card out of my sight when I pay at restaurants, either.
posted by ArkhanJG at 12:34 AM on March 23, 2009
Now, we can assume that he's doing this in the first place to snoop on people's web traffic. He will receive everything that's sent in the clear. Take gmail for example - by default, if you go to the unencrypted page, it will switch to https for the login and password, but the rest of your email browsing will be sent in the clear, and the snooper will get the lot. Quite a lot of sites still don't even default to https for login.
Lots of websites do this. In gmail's specific case, you can change an option in the settings so it defaults to using https always, and you can also manually go to the https site first.
If you're checking email via POP or IMAP, connecting unencrypted is usually still the default for many providers, you have to manually change it to using a secure SSL channel - and anything sent unencrypted is easily snooped. Equally, many sites still send information in the clear, even logins.
This is what he'll be trying to get - it's low hanging fruit, and there's a lot of it. You can steal identities, compromise email accounts (and then use those to get access to lots of other websites), get personal info of all sorts, that's just sent out entirely in the clear.
SSL sites are pretty secure. The tech for the encryption itself is still safe; if you connect to the real site, with a real certificate, any snooper will simply not be able to listen in on that traffic, it's what it's designed to do, and there's no practical way round it for a hacker.
The exploits for SSL rely on social engineering - either putting up a fake site and hoping people ignore the bad certificate warnings, or exploiting weaknesses in our trust for the many, many certificate authorities, and exploiting a weakness in the way some are issued to get genuine certificates you're not supposed to have so the fake site looks genuine. Or hell, just redirecting you to the unencrypted site, so you end up using the unsecured site instead of the secured one you thought you were going to.
The odds that someone is going to go to that level of sneakiness, and then spend their time hanging around a starbucks is simply not very likely at all. Not when he get so much easily, just by going for the the low-hanging unencrypted fruit.
I mean, he could sit there and insert malware by replacing the adverts, turning every unencrypted site you go to into a drive-by download site - use that to install a keylogger, and he gets everything you type, whether it's in an encrypted site or not.
If you pay attention to bad certificates, keep your system patched and free from malware, have a good firewall and up to date antivirus, and only visit SSL sites, yes, you're safe enough as a general practical measure, even if someone is listening in. Skilled hackers are going to be off writing the next conficker or showing off their brilliant browser exploit at a hacker conference, not hanging around starbucks trying to spoof bankofamerica.com.
That said - I have a linux box at home which I use for online banking. I don't do it on public networks, I don't even do it on windows at home; but as I said, I'm more paranoid with online security than most. I don't let my credit card out of my sight when I pay at restaurants, either.
posted by ArkhanJG at 12:34 AM on March 23, 2009
someone who is watching constantly may be able to catch the key exchange between your browser and the server, which would allow them to decrypt the message
No this is wrong. Think about it for a little bit. If public-key crypto worked this way, when would it ever be secure?
SSL encrypts traffic from your box all the way to the host. There are attacks that someone could mount, Man-in-the-Middle attacks which have been outlined above, but really, you are probably safe 'enough'.
posted by chunking express at 7:25 AM on March 23, 2009 [1 favorite]
No this is wrong. Think about it for a little bit. If public-key crypto worked this way, when would it ever be secure?
SSL encrypts traffic from your box all the way to the host. There are attacks that someone could mount, Man-in-the-Middle attacks which have been outlined above, but really, you are probably safe 'enough'.
posted by chunking express at 7:25 AM on March 23, 2009 [1 favorite]
No problems. Your quite safe when using SSL. You can read the cert by clicking on the lock if your concerned. You can also see if your employer offers VPN services.
posted by jeffburdges at 12:14 PM on April 26, 2009
posted by jeffburdges at 12:14 PM on April 26, 2009
This thread is closed to new comments.
posted by kbanas at 2:08 PM on March 22, 2009