Hey, Verizon, 1995 called and they want their information security level back.



  • I recently had my Visa number hijacked and used for all sorts of unsavory online purchases. So, I had that one blocked and a new card issued. Now I have to make sure all of my auto-payment arrangements have up-to-date info. Verizon beat me to it and sent me an email saying that my card couldn't be validated. OK, this should be simple... I'll just go to the online account access at http://verizon.net (yes, that is a real Verizon domain).

    So I log in and navigate through all of the pages, feeling snug and secure in their usage of https... until I get to the credit card info screen... which uses plain ol' HTTP!? I tried manually changing the protocol for the URL to HTTPS, but it redirected me back to using HTTP. I checked the source of the page, and the form's action is HTTP, of course. So I had to make the dreaded phone call, getting transferred 4 times and spending 25 minutes updating my freaking credit card info.

    WTF Verizon? Are you really this pathetically incompetent? Do you really expect me to submit my credit card number insecurely when I've just had it stolen? Your site looks like one of those sad phishing sites. Bang up job, keep up the good work, you jackasses.



  • You have to think about it from their point of view.  It's so much simpler for them if, instead of going to all the effort of having security which will inevitably be broken, they just have no security in the first place.



  • What you didn't know is that I am the one who registered verizon.net.  Foiled again!



  • 2000 called, and they want their joke back.  And could you send priceless back with it.



  • Eh, unless you are on a crappy public network where anyone can sniff traffic it's unlikely that SSL will make much of a difference.  It's slightly better than unencrypted HTTP, but if someone can sniff your network traffic with impunity they can most likely modify it and you are as good as pwn3d. 



  • @morbiuswilters said:

    Eh, unless you are on a crappy public network where anyone can sniff traffic it's unlikely that SSL will make much of a difference.  It's slightly better than unencrypted HTTP, but if someone can sniff your network traffic with impunity they can most likely modify it and you are as good as pwn3d.
    Are you speaking specifically of public wireless networks, or any public network?

    Because I always figured wireless encryption was pointless because anything you're doing that you need to have secure is going to be encrypted with ssl anyway.  If someone really wants to sniff my packets to stream my donkey porn, they can just come over and look over my shoulder.

    That said, I still encrypt the wireless network in my apartment.  It keeps the undesirables out, like anyone who wants to use my internet connection for unsanctioned (read: non-donkey-porn) internet browsing.



  • @morbiuswilters said:

    Eh, unless you are on a crappy public network where anyone can sniff traffic it's unlikely that SSL will make much of a difference. It's slightly better than unencrypted HTTP, but if someone can sniff your network traffic with impunity they can most likely modify it and you are as good as pwn3d.

    If by "most likely" you mean "according to this notion I pulled out of my ass." The whole point of signed certificates and CAs is to prevent the man-in-the-middle attacks you are talking about.



  • @djork said:

    @morbiuswilters said:

    Eh, unless you are on a crappy public network where anyone can sniff traffic it's unlikely that SSL will make much of a difference. It's slightly better than unencrypted HTTP, but if someone can sniff your network traffic with impunity they can most likely modify it and you are as good as pwn3d.

    If by "most likely" you mean "according to this notion I pulled out of my ass." The whole point of signed certificates and CAs is to prevent the man-in-the-middle attacks you are talking about.

    *sigh*  Obviously that's the point of SSL.  The thing is, if someone can sniff and manipulate your traffic, they can find some other way to hijack your machine (like through modification of a downloaded binary) which will circumvent SSL altogether.  The point is, it's much easier to attack the end-points than the channel in betwixt.



  •  I believe the real WTF is being afraid of someone stealing your CC.

     

    Run up my bill, go nuts. I'm not paying a dime! 



  • @morbiuswilters said:

    Eh, unless you are on a crappy public network where anyone can sniff traffic it's unlikely that SSL will make much of a difference.  It's slightly better than unencrypted HTTP, but if someone can sniff your network traffic with impunity they can most likely modify it and you are as good as pwn3d. 

     

    How would the ability to modify encrypted traffic lead to pwn4g3?  If I haven't got the private key, I can't decrypt the request, so the best I could do would be to corrupt it and end up with an unreadable stream at the server.  There's definitely no way I'd be able to get the credit card number.

    Unless you're suggesting that someone would actually be redirecting all of that SSL traffic to their own phishing server with their own SSL cert, but that sounds pretty far-fetched.  It's more likely that some disgruntled IT employee at the ISP or one of their upstream providers decided to take a peek.  Or if you're in a shared facility like a university dorm, that some script kiddie down the hall decided to have some fun with Ethereal.

    The best option is a mutual certificate scenario; that way the client uses a specific public key that they know is trusted, not whatever key the server happens to drop on them.  But those are kind of a pain in the ass to maintain, especially on the public internet.  If your key ever got compromised or you decided to switch from VeriSign to GeoTrust then you'd be in a world of hurt.

    I think SSL is a reasonable compromise between security and practicality.  If you have a better idea I'd like to hear it.

     

    Edit: I just read your subsequent reply.  That makes a little more sense, but I still think the likelihood is remote compared to someone just sniffing traffic.  Packet monkeys don't know how to hijack requests and substitute downloaded binaries with worms.



  • @Aaron said:

    @morbiuswilters said:

    Eh, unless you are on a crappy public network where anyone can sniff traffic it's unlikely that SSL will make much of a difference.  It's slightly better than unencrypted HTTP, but if someone can sniff your network traffic with impunity they can most likely modify it and you are as good as pwn3d. 

     

    How would the ability to modify encrypted traffic lead to pwn4g3?  If I haven't got the private key, I can't decrypt the request, so the best I could do would be to corrupt it and end up with an unreadable stream at the server.  There's definitely no way I'd be able to get the credit card number.

    Unless you're suggesting that someone would actually be redirecting all of that SSL traffic to their own phishing server with their own SSL cert, but that sounds pretty far-fetched.  It's more likely that some disgruntled IT employee at the ISP or one of their upstream providers decided to take a peek.  Or if you're in a shared facility like a university dorm, that some script kiddie down the hall decided to have some fun with Ethereal.

    The best option is a mutual certificate scenario; that way the client uses a specific public key that they know is trusted, not whatever key the server happens to drop on them.  But those are kind of a pain in the ass to maintain, especially on the public internet.  If your key ever got compromised or you decided to switch from VeriSign to GeoTrust then you'd be in a world of hurt.

    I think SSL is a reasonable compromise between security and practicality.  If you have a better idea I'd like to hear it.

     

    Edit: I just read your subsequent reply.  That makes a little more sense, but I still think the likelihood is remote compared to someone just sniffing traffic.  Packet monkeys don't know how to hijack requests and substitute downloaded binaries with worms.

    I never said anything about reading the SSL traffic.  My point was that if your connection can be sniffed (the reason plain HTTP wouldn't be secure enough) then an attack can just attack your machine through some other channel, like injecting malware.



  • @morbiuswilters said:

    @djork said:

    @morbiuswilters said:

    Eh, unless you are on a crappy public network where anyone can sniff traffic it's unlikely that SSL will make much of a difference. It's slightly better than unencrypted HTTP, but if someone can sniff your network traffic with impunity they can most likely modify it and you are as good as pwn3d.

    If by "most likely" you mean "according to this notion I pulled out of my ass." The whole point of signed certificates and CAs is to prevent the man-in-the-middle attacks you are talking about.

    *sigh*  Obviously that's the point of SSL.  The thing is, if someone can sniff and manipulate your traffic, they can find some other way to hijack your machine (like through modification of a downloaded binary) which will circumvent SSL altogether.  The point is, it's much easier to attack the end-points than the channel in betwixt.

    OK, so help me out here, and let me know if I missed anything:

    1. I navigate to a web page
    2. I get a verified SSL certificate signed by a trusted CA
    3. ... ?
    4. OMG TEH HAXXORS HAXXORED MY BOX AND ITZ HAXXORED NOW WUT DO I DO!?!?!?!?!?!!!!1 O NO


  • @morbiuswilters said:

    I never said anything about reading the SSL traffic.  My point was that if your connection can be sniffed (the reason plain HTTP wouldn't be secure enough) then an attack can just attack your machine through some other channel, like injecting malware.

    "Injecting malware" is a hell of a lot harder than sniffing unencrypted HTTP traffic. The sort of attack you are describing is a "movie plot threat" for geeks.



  • @djork said:

    So I log in and navigate through all of the pages, feeling snug and secure in their usage of https... until I get to the credit card info screen... which uses plain ol' HTTP!?

    TRWTF is that they don't use frames to mediate securely.



  • Getting back to the origional post, just because the form isn't SSL encryped doesn't mean that it won't be encryped when you acutally hit the send button.  Check the action of the form in the HTML source, and if it POSTs to an https:// connection, you're good.  (Incidentally, this works the other way around, too.  It's quite possible to have an SSL encoded form that ends up sending everything in the clear anyway, because the action of the form wasn't encrypted.  Doing this would be a huge WTF.)

     That said, it's still a bit of a WTF if that's what they're doing, because you'd still want the form itself encrypted for no other reason then to prove to the user that you can, in fact, do encryption.  Forcing the user to check the source to find out that it'll be encrypted in a second is rather dumb.



  • @djork said:

    I checked the source of the page, and the form's action is HTTP, of course.

    @Howitzer said:

    Check the action of the form in the HTML source, and if it POSTs to an https:// connection, you're good.



  • @djork said:

    @morbiuswilters said:

    @djork said:

    @morbiuswilters said:

    Eh, unless you are on a crappy public network where anyone can sniff traffic it's unlikely that SSL will make much of a difference. It's slightly better than unencrypted HTTP, but if someone can sniff your network traffic with impunity they can most likely modify it and you are as good as pwn3d.

    If by "most likely" you mean "according to this notion I pulled out of my ass." The whole point of signed certificates and CAs is to prevent the man-in-the-middle attacks you are talking about.

    *sigh*  Obviously that's the point of SSL.  The thing is, if someone can sniff and manipulate your traffic, they can find some other way to hijack your machine (like through modification of a downloaded binary) which will circumvent SSL altogether.  The point is, it's much easier to attack the end-points than the channel in betwixt.

    OK, so help me out here, and let me know if I missed anything:

    1. I navigate to a web page
    2. I get a verified SSL certificate signed by a trusted CA
    3. ... ?
    4. OMG TEH HAXXORS HAXXORED MY BOX AND ITZ HAXXORED NOW WUT DO I DO!?!?!?!?!?!!!!1 O NO

    Oh FFS..  How do you people keep getting stupider?

     

    The point is sniffing unencrypted HTTP traffic is not a particularly useful vector for attack.  It's much easier to just attack the end-points, specifically the server.  This would give access to far more sensitive data than simple sniffing of traffic would.  And despite what you seem to think, modifying unencrypted traffic isn't terribly complex and would be a fairly easy way to compromise a client computer.  If someone can sniff your network traffic, then it's very likely they can modify that traffic as well.  Is any of this getting through?



  • @DeLos said:

    I believe the real WTF is being afraid of someone stealing your CC.

    Run up my bill, go nuts. I'm not paying a dime!

    Yes, but it takes time to appeal the charges, put a block on that CC, get a new CC, update any auto payments on it...

    Would you like to go through that?

    Trying to prevent your CC# from being stolen is not a WTF.



  • @morbiuswilters said:

    It's much easier to just attack the end-points, specifically the server.  This would give access to far more sensitive data than simple sniffing of traffic would.

    I'm not sure what your point is. Should we all just throw our hands up and stop using HTTP, because at any moment someone might inject and somehow install a piece of malware by taking advantage of a zero-day exploit in your specific browser's image decompression library next time you load a web page?

    Here's the deal: HTTPS [i][b]WORKS[/b][/i] and it is [i][b]SAFE[/b][/i]. That's what this discussion is about. If you want to talk about injecting malware in HTTP responses then go ahead and be my guest. I am running Mac OS X 10.5 and use Safari 3.1.2. Let me know when you have a detailed explanation of the vector and the payload and maybe I'll even try it out for you!



  • @djork said:

    Let me know when you have a detailed explanation of the vector and the payload and maybe I'll even try it out for you!
    Don't wait for him to come up with sources.



  • @djork said:

    @morbiuswilters said:
    It's much easier to just attack the end-points, specifically the server.  This would give access to far more sensitive data than simple sniffing of traffic would.

    I'm not sure what your point is. Should we all just throw our hands up and stop using HTTP, because at any moment someone might inject and somehow install a piece of malware by taking advantage of a zero-day exploit in your specific browser's image decompression library next time you load a web page?

    Here's the deal: HTTPS WORKS and it is SAFE. That's what this discussion is about. If you want to talk about injecting malware in HTTP responses then go ahead and be my guest. I am running Mac OS X 10.5 and use Safari 3.1.2. Let me know when you have a detailed explanation of the vector and the payload and maybe I'll even try it out for you!

    Wow, I figured you would have to be mentally retarded to not understand my point and your use of a Mac confirms this.  I never said people should stop using HTTPS, but instead that not using HTTPS isn't that big of a deal.  If somebody is sniffing your traffic, you have bigger problems.  And no, I'm not going to waste my time listing OS X vulnerabilities.  Get off your fat ass and look them up yourself. 



  • @morbiuswilters said:

    figured you would have to be mentally retarded to not understand my point and your use of a Mac confirms this.

    @morbiuswilters said:

    not using HTTPS isn't that big of a deal

    I should have picked up on it earlier! You're just a troll! It all makes sense now...



  • @djork said:

    @morbiuswilters said:
    figured you would have to be mentally retarded to not understand my point and your use of a Mac confirms this.

    @morbiuswilters said:

    not using HTTPS isn't that big of a deal

    I should have picked up on it earlier! You're just a troll! It all makes sense now...

    Right.  I'm a troll because people who use Macs tend to be significantly less intelligent than people who use Windows (as proven by an independent survey conducted by me).  Oh and because I understand that SSL protects against a threat that really isn't significant and does nothing to stop the real security threats.

     

    *slow clap*



  • @morbiuswilters said:

    If somebody is sniffing your traffic, you have bigger problems.
    I've always been under the opinion that my traffic IS being sniffed and there's nothing I can do about that, short of downloading so much donkey porn that noone WANTS to sniff it anymore ... or encrypting the traffic.



  • @belgariontheking said:

    @morbiuswilters said:

    If somebody is sniffing your traffic, you have bigger problems.
    I've always been under the opinion that my traffic IS being sniffed and there's nothing I can do about that, short of downloading so much donkey porn that noone WANTS to sniff it anymore ... or encrypting the traffic.

    I dunno, donkey porn smells pretty good to me. 



  • On one level I agree with morbius, if someone is tampering with your traffic they could easily detect you downloading an executable and send you a piece of malware instead. Once you run that on a windows box there's very little that can't be done (Hell, I'm sure if you went to enough trouble you could probably screw with the DLL's that do SSL certificate validation to allow man in the middle again...

    That said, that's far more sophisticated than just sending "omg look at this new video <exe attached>" and against 90% of users will jsut run it so I can't see any malware writers doing that much effort. But with clear HTTP traffic all you need to do is find a way to get a copy of a decent quantity of traffic and just run each line through a scan to grab credit card details out of the post data. Far simpler, but still highly impractical when there's much simpler attack vectors available.



  • @morbiuswilters said:

    The point is sniffing unencrypted HTTP traffic is not a particularly useful vector for attack.  It's much easier to just attack the end-points, specifically the server.  This would give access to far more sensitive data than simple sniffing of traffic would.  And despite what you seem to think, modifying unencrypted traffic isn't terribly complex and would be a fairly easy way to compromise a client computer.  If someone can sniff your network traffic, then it's very likely they can modify that traffic as well.  Is any of this getting through?
     

    I tend to agree with HTTPS not being an especially useful vector of attack, but it still is kind of WTFish that they protect a large portion of the site with SSL, then stop and prevent it when you type in your CC.  

    It also doesn't inspire confidence in the rest of their security measures either, and if a CC was sniffed I wonder if they'd be considered legally negligent. 


Log in to reply