2 ms·

> This ain’t new to me. Respectfully, you were mistaken on several points of fact. It's quite clear that some of this stuff is new to you. > No successful hac

> This ain’t new to me. Respectfully, you were mistaken on several points of fact. It's quite clear that some of this stuff is new to you. > No successful hacking attempts so far on my watch. HTTPS doesn't protect a website against intruders, nor is it meant to. That's a whole different conversation. > Everyone feels so safe using HTTPS but when it cracks we are going to be screwed Is your issue with diversity of implementations, or with diversity of underlying algorithms? The cyber-security community has collectively agreed that it's best to maintain relatively few cryptography codebases well, rather than maintain many of them. So yes, if there are flaws in libraries like OpenSSL, that's a big problem, but experience shows that this approach is far better than using half-baked crypto solutions. The worst security of all is where the crypto is provided by a half-baked 'custom' solution thrown together by well-meaning amateurs, never subjected to critical review by serious cryptographers. Ideally I'd like to see things go even further in the current direction: we should be using formally verified implementations of TLS. That would close the door on issues like HeartBleed. The only issues remaining would be side-channel attacks, and advances in cryptography that defeat the underlying cryptographic approach. > What’s stops a corporation/CA from revoking a certificate because you threaten their business? Has this ever happened? If it did, I'd report them to the CA/Browser Forum, and get a replacement cert from a different CA. > I wouldn’t touch let’s encrypt with a barge poll. If I want a SSL i’d rather fork out in a paid cert as at least there is insurance behind. I agree that you need to be able to trust your CA, especially as the web moves toward short-lived certs. If your CA has an issue, your whole site disappears from the web. So far, I think all the major CAs have a pretty good reputation when it comes to reliability, but I'm not very experienced in that area. > When google can create their own CA authority how is that secure? Look at google certs, they’ve planted their own global root cert in your OS without you even approving it. I'm afraid I don't know what you're referring to. Does Chrome install root certs into Windows when installed? If so, I agree that Google shouldn't be doing that. As for Google being a CA: I'm not too worried about that. When it comes to the imperfections of the CA system, there are worse issues than Google being on the list. > HTTPS is lazy, might be easy but poor mans security. What's the alternative? A web-of-trust approach would greatly complicate things, compared to the current approach using CAs. I don't know what you mean by 'easy'. What do you have in mind? Again, whatever the solution, the website's own code cannot secure the channel. Right now, HTTPS is the only game in town, and it works pretty well.

doublerabbit 7y ago
It’s all moot as I said. It is the only game in town and the game is whack-a-mole. The mole will be whacked and we will be screwed. As is running out of IPv4 addresses. I just decided not to stance on such issues like self-signed as it’s a pointless to go down that rabbit hole. >Respectfully, you were mistaken on several points of fact. It's quite clear that some of this stuff is new to you Sure, why not. I’ve withheld my bragging but thirteen years of depressing soul destroying System Operator/Administrator experience including Linux,Unix,Solaris and *BSD within high secure data centres,banks,pornography,animation,telecoms who knows what else. Two years is the max I can take because the field, software, hardware is so stale it hurts. I still disagree you can encrypt and secure the channel within a app. Why would it be impossible? > What's the alternative? self signed certificates. moot. take it as you wish.
- MaxBarraclough 7y ago
  I caught you mid-edit so forgive some stale quotes: > It’s all moot as I said It absolutely isn't. Security matters. HTTPS matters. This stuff is real. When a website argues for why it shouldn't bother with HTTPS, it's generally because they don't know what they're talking about, and they end up putting users at risk. Personal favourite: [0] > It’s the only game in town and the game is whack-a-mole. HTTPS is doing pretty well. There's always some element of whack-a-mole with security matters like this. (Personally I favour different metaphorical mammals: cat and mouse.) Even OpenBSD doesn't have a perfect record. Perfection shouldn't be the enemy of progress. We have online banking and online tax forms thanks to HTTPS, for instance. Without crypto, these simply wouldn't be possible. When we read of lawyers using fax machines, that shouldn't reassure us that plaintext HTTP is perfectly fine, it should alarm us that such an important profession has such inadequate security practices. > As is running out of IPv4 addresses. I agree this isn't exactly a good situation, but it's not going to paralyse the Internet. Worst case: the price of an IP goes up. Best case: IPv6 at last. > And yes, you can encrypt the channel within a app You've ignored the point I made. Are we talking about a web app, or a conventional app? If it's a conventional app: yes, you can layer your own cryto atop raw TCP, but it's a terrible idea. You should use HTTPS, or use TLS directly, or if you're in a Unix mood you could use SSH. There is no reason for doing otherwise. You cannot avoid the questions of key-management by handling the crypto yourself, you're not improving anything fundamentally, all you're doing is risking introducing easily-avoided security bugs. If it's a web app: you simply cannot, because you have to securely deliver the crypto software to the end-user, which you cannot do without HTTPS. > I just decided not to debate those issues as such as self signed as it’s a pointless to go on about Do please go ahead. The point of HN is discussion, after all. > self signed certificates. These do not protect you against a man-in-the-middle attack. They do not protect you from connecting to a host under the control of an attacker, posing as the real host. They only give you protection against passive data-capture. That, and a false sense of security. Were you unaware of this? [0] https://arstechnica.com/information-technology/2017/03/firefox-gets-complaint-for-labeling-unencrypted-login-page-insecure/ https://arstechnica.com/information-technology/2017/03/firef...

doublerabbit 7y ago

It’s all moot as I said. It is the only game in town and the game is whack-a-mole. The mole will be whacked and we will be screwed. As is running out of IPv4 addresses. I just decided not to stance on such issues like self-signed as it’s a pointless to go down that rabbit hole. >Respectfully, you were mistaken on several points of fact. It's quite clear that some of this stuff is new to you Sure, why not. I’ve withheld my bragging but thirteen years of depressing soul destroying System Operator/Administrator experience including Linux,Unix,Solaris and *BSD within high secure data centres,banks,pornography,animation,telecoms who knows what else. Two years is the max I can take because the field, software, hardware is so stale it hurts. I still disagree you can encrypt and secure the channel within a app. Why would it be impossible? > What's the alternative? self signed certificates. moot. take it as you wish.

MaxBarraclough 7y ago
I caught you mid-edit so forgive some stale quotes: > It’s all moot as I said It absolutely isn't. Security matters. HTTPS matters. This stuff is real. When a website argues for why it shouldn't bother with HTTPS, it's generally because they don't know what they're talking about, and they end up putting users at risk. Personal favourite: [0] > It’s the only game in town and the game is whack-a-mole. HTTPS is doing pretty well. There's always some element of whack-a-mole with security matters like this. (Personally I favour different metaphorical mammals: cat and mouse.) Even OpenBSD doesn't have a perfect record. Perfection shouldn't be the enemy of progress. We have online banking and online tax forms thanks to HTTPS, for instance. Without crypto, these simply wouldn't be possible. When we read of lawyers using fax machines, that shouldn't reassure us that plaintext HTTP is perfectly fine, it should alarm us that such an important profession has such inadequate security practices. > As is running out of IPv4 addresses. I agree this isn't exactly a good situation, but it's not going to paralyse the Internet. Worst case: the price of an IP goes up. Best case: IPv6 at last. > And yes, you can encrypt the channel within a app You've ignored the point I made. Are we talking about a web app, or a conventional app? If it's a conventional app: yes, you can layer your own cryto atop raw TCP, but it's a terrible idea. You should use HTTPS, or use TLS directly, or if you're in a Unix mood you could use SSH. There is no reason for doing otherwise. You cannot avoid the questions of key-management by handling the crypto yourself, you're not improving anything fundamentally, all you're doing is risking introducing easily-avoided security bugs. If it's a web app: you simply cannot, because you have to securely deliver the crypto software to the end-user, which you cannot do without HTTPS. > I just decided not to debate those issues as such as self signed as it’s a pointless to go on about Do please go ahead. The point of HN is discussion, after all. > self signed certificates. These do not protect you against a man-in-the-middle attack. They do not protect you from connecting to a host under the control of an attacker, posing as the real host. They only give you protection against passive data-capture. That, and a false sense of security. Were you unaware of this? [0] https://arstechnica.com/information-technology/2017/03/firefox-gets-complaint-for-labeling-unencrypted-login-page-insecure/ https://arstechnica.com/information-technology/2017/03/firef...