4 ms·

Firefox gets complaint for labeling unencrypted login page insecure

18 points by gvb 10y ago

skarap 10y ago
Would be nice to have an option to disable this for intranets. Otherwise - a very good thing to do.
- 50CNT 10y ago
  Couldn't you just set up a Private CA since you'd have to customize things anyways?
  - majewsky 10y ago
    Exactly. You should never consider a network perfectly secure, no matter if it is the internet or your intranet.
K0nserv 10y ago
I was sympatehtic of the site owner until I read that they are sending credit card information over HTTP on a page that claims to be doing so securely. With that level of negligence they deserve what they get here
- jacquesm 10y ago
  Still, the chances of that number being caught 'in transit' are a lot smaller than the chances of it being caught 'at rest'. The risk here is mostly in exploits on the page and absent those you're going to have to trust the party on the other end to keep your data safe or to not keep it at all. It's a risk roughly equivalent to speaking on the phone to a hotel registry and giving them your CC#, or a car rental agency. And in that case, at least one other person now has your number (and that's besides all the other people that already have the numbers and those that handled the card in your absence, waiters in restaurants and so on). Credit Cards working without something along the lines of VBV is a bug, not a feature and the fact that 'just a number' is worth money is where the real problem lies, not in how it got transmitted, that's just a reduction of the risk, not an elimination. All that said there is absolutely no excuse why they should not use HTTPS, and it also makes you very wary of doing business with this party at all, likely their other security sucks.
probably_wrong 10y ago
Previously discussed here: https://news.ycombinator.com/item?id=13917778 https://news.ycombinator.com/item?id=13917778
- AndrewDucker 10y ago
  It's marked as a dupe (and presumably flagged) despite the original story now linking to a locked Bugzilla entry, with no information about context. Could we un-dupe it?
- molecule 10y ago
  Additionally, as pointed out in this article, the original linked article is now locked: > You are not authorized to access bug 1348902. To see this bug, you must first log in to an account with the appropriate permissions.
deleted 10y ago
[deleted]
pdpi 10y ago
> Update: As several commenters have pointed out, the site's subscription page[0] transmits credit card information over plain-vanilla HTTP pages as well. 0. http://www.oilandgasinternational.com/SSL_Subscribe/subscribe_us.aspx http://www.oilandgasinternational.com/SSL_Subscribe/subscrib...
- tyingq 10y ago
  It's got other issues as well. It spewed an error page for me with snippets of source code. http://imgur.com/a/UiPDf http://imgur.com/a/UiPDf

18 points by gvb 10y ago

skarap 10y ago

Would be nice to have an option to disable this for intranets. Otherwise - a very good thing to do.

50CNT 10y ago
Couldn't you just set up a Private CA since you'd have to customize things anyways?
- majewsky 10y ago
  Exactly. You should never consider a network perfectly secure, no matter if it is the internet or your intranet.

K0nserv 10y ago

I was sympatehtic of the site owner until I read that they are sending credit card information over HTTP on a page that claims to be doing so securely. With that level of negligence they deserve what they get here

jacquesm 10y ago
Still, the chances of that number being caught 'in transit' are a lot smaller than the chances of it being caught 'at rest'. The risk here is mostly in exploits on the page and absent those you're going to have to trust the party on the other end to keep your data safe or to not keep it at all. It's a risk roughly equivalent to speaking on the phone to a hotel registry and giving them your CC#, or a car rental agency. And in that case, at least one other person now has your number (and that's besides all the other people that already have the numbers and those that handled the card in your absence, waiters in restaurants and so on). Credit Cards working without something along the lines of VBV is a bug, not a feature and the fact that 'just a number' is worth money is where the real problem lies, not in how it got transmitted, that's just a reduction of the risk, not an elimination. All that said there is absolutely no excuse why they should not use HTTPS, and it also makes you very wary of doing business with this party at all, likely their other security sucks.

probably_wrong 10y ago

Previously discussed here: https://news.ycombinator.com/item?id=13917778 https://news.ycombinator.com/item?id=13917778

AndrewDucker 10y ago
It's marked as a dupe (and presumably flagged) despite the original story now linking to a locked Bugzilla entry, with no information about context. Could we un-dupe it?
molecule 10y ago
Additionally, as pointed out in this article, the original linked article is now locked: > You are not authorized to access bug 1348902. To see this bug, you must first log in to an account with the appropriate permissions.

deleted 10y ago

[deleted]

pdpi 10y ago

> Update: As several commenters have pointed out, the site's subscription page[0] transmits credit card information over plain-vanilla HTTP pages as well. 0. http://www.oilandgasinternational.com/SSL_Subscribe/subscribe_us.aspx http://www.oilandgasinternational.com/SSL_Subscribe/subscrib...

tyingq 10y ago
It's got other issues as well. It spewed an error page for me with snippets of source code. http://imgur.com/a/UiPDf http://imgur.com/a/UiPDf