3 ms·

> only because we don’t have a public CA for self-signed or a mechanism to cover So, generate your own cert and then have a CA validate it? That's just a clums

> only because we don’t have a public CA for self-signed or a mechanism to cover So, generate your own cert and then have a CA validate it? That's just a clumsier variation on what we have today, where the CA generates the cert for you with the validation 'baked in'. If you still need CAs, what's the advantage? > Self signed can provide false sense of security but it’s still a certificate which provides encrypted passage that if you were to hypothetically say they were being used genuinely. That's wrong. Using self-signed certs, the client doesn't have any idea whether it's connecting to the intended host. This is the entire point of CAs. > LetsEncrypt is essentially self-signed cert by submitter to a database owned by whoever. With a root certificate held up by Operating System creators. That's not the case. 1. You don't submit a cert to LetsEncrypt for approval. They give you the cert. 2. LetsEncrypt won't give you a cert unless you can prove you are truly the owner of the domain. We can quibble about whether their checks are adequate, but it's not correct to say it's the equivalent of a self-signed cert. 3. There is no root cert held by the OS creators. The OS maintains a list of trusted CAs, but the OS vendor doesn't do any signing. > If I was to create an OS and not include the LetsEncrypt CA then errors would be thrown. Correct. > It’s a requirement for the internet for now but putting all your eggs in one basket like LE, I’d rather let mine be cracked with insurance. Like I said, rolling your own crypto is a bad idea. This isn't a matter of opinion. > Within a webApp you can and If the simple principle of HTTP is “Give me index.html” to which the contents of the file are then submitted and spewed our by that browser > read file > encrypt with some cipher > decrypt > user > Sure the packet can be mangled but based off your browser checksum the data is still not accessible. This is wrong. If data is sent over HTTP, it can be maliciously modified by an attacker. I suspect you're thinking of the use of checksums to detect errors in network transmission. That's not relevant here. > You can even then add your own packet checksum. You cannot do this in a way that has any real bearing on security. Where would you put it? In JavaScript, sent unprotected over plaintext HTTP? > Is a simple poll which uses text files instead of database. However without SSL and using naviserver (TCL) as my web server for now. Encrypted using Blowfish. What's encrypted? The page is delivered over plaintext HTTP. That's why my browser is warning me. > All HTML is encrypted from first visit to submission result. The HTML is not encrypted, it's send unprotected using HTTP. The page is completely unsecured. > The template files are stored in Hex encrypted, then decrypted, them ecrypto’s again for the user and then decrypted. So the data is stored in encrypted form, then decrypted prior to being sent over unprotected HTTP? > HTTPs would be another coat of armour and that would which would be capturing which post you make. No, HTTPS is the only armour you have. Everything else is just playing with sand. There's a very good reason Google don't put crypto code in JavaScript, and it's not because they didn't think of it. It cannot be done. > However I now need to encrypt the users click packet of POST. > Connection Open > Html spewed > Connection closed User clicks option > Post result encrypted > update results file > It's not clear what you're really saying here. I should emphasise yet again, that you do not have an alternative to HTTPS here. > I hate using my phone for in-depth discussions of my views which is why I’m obmitting answers + the UI of HN isn’t the greatest when you have a seven line box to type in. I'm sure you're right, I've never tried. My habit is to note down HackerNews comment ID numbers on my phone, then type up responses when I get back to my laptop. > Can we just end this? I’m not stupid, I understand, but my own beliefs disagrees with the concepts currently in place. I mean no insult here, but it's plain that you don't understand what HTTPS does, how it works, what CAs are for, why self-signed certificates are inadequate, and why it's hopeless to try to make plaintext HTTP equivalently secure. You have not invented an HTTP-based alternative to HTTPS. There isn't one. There never will be one. It cannot be done. > The internet I feel is on-life support to where it’s erupted with corporate greed who’s drilling it in to the ground. Like fracking. Several people, including myself, have already told you about LetsEncrypt.

zozbot234 7y ago
> That's wrong. Using self-signed certs, the client doesn't have any idea whether it's connecting to the intended host. TOFU is a possibility. That's essentially what happens when you click through the self-signed cert warning, and opt to make that exception permanent. Not something that should be expected from a naïve end-user (which is why a scary warning is appropriate) but technically feasible nonetheless.
- MaxBarraclough 7y ago
  If you trust blindly on first use, you're wide open to an impersonation attack. That isn't a solution, it's giving up. That was my point. This is why browsers are increasingly hostile to self-signed certs, which users should never see. It's the same reason SSH clients prompt you to manually confirm the expected fingerprint when connecting to a new server, rather than accepting it on faith, which is what you're suggesting.
  - zozbot234 7y ago
    No one's saying that you should trust "blindly". The whole point of having a "hostile" warning when encountering a self-signed cert is protecting the user from impersonation attacks. But if you've established trust in other ways (such as by verifying the cert via an out-of-band channel, or because you set it up yourself) TOFU should be available.
    - MaxBarraclough 7y ago
      > No one's saying that you should trust "blindly". Gotcha. Quick digression: I'm not a fan of the term 'trust on first use', as it can very reasonably be interpreted to mean exactly that. I mean, that's what is says... Wikipedia even gives it as one of its two almost antonymous definitions of the term, i.e. it can mean on first use, manually confirm whether to trust, or it can mean on first use, blindly trust. > The whole point of having a "hostile" warning when encountering a self-signed cert is protecting the user from impersonation attacks. There's a strong argument to be made that if you really want to protect the end-user from impersonation attacks, you shouldn't even give them the option of proceeding. Unfortunately, users are conditioned to click through warnings uncritically. > if you've established trust in other ways (such as by verifying the cert via an out-of-band channel, or because you set it up yourself) TOFU should be available In principle, sure, but what's the use-case here? We already have a secure, scalable, fool-proof solution to the problem: CAs. We insist upon CAs, because there's no good reason not to use them for all public-facing websites. What's the use-case here? If you want to run your own personal network, and your own personal alternative DNS scheme, you're free to set up your own personal CA for the purpose. Corporate networks do this. I see no reason to chuck out the whole concept of CAs. SSH is a different beast, as it's not intended for use by non-technical users. It's reasonable to insist on your sysadmin manually checking SSH fingerprints. Not so for non-technical users and HTTPS certs. Even in the case of SSH, CAs are a good solution if you're working at scale. To my knowledge, the only thing approaching a serious alternative to CAs, is web-of-trust, but it's not really a practical alternative.

zozbot234 7y ago

> That's wrong. Using self-signed certs, the client doesn't have any idea whether it's connecting to the intended host. TOFU is a possibility. That's essentially what happens when you click through the self-signed cert warning, and opt to make that exception permanent. Not something that should be expected from a naïve end-user (which is why a scary warning is appropriate) but technically feasible nonetheless.

MaxBarraclough 7y ago
If you trust blindly on first use, you're wide open to an impersonation attack. That isn't a solution, it's giving up. That was my point. This is why browsers are increasingly hostile to self-signed certs, which users should never see. It's the same reason SSH clients prompt you to manually confirm the expected fingerprint when connecting to a new server, rather than accepting it on faith, which is what you're suggesting.
- zozbot234 7y ago
  No one's saying that you should trust "blindly". The whole point of having a "hostile" warning when encountering a self-signed cert is protecting the user from impersonation attacks. But if you've established trust in other ways (such as by verifying the cert via an out-of-band channel, or because you set it up yourself) TOFU should be available.
  - MaxBarraclough 7y ago
    > No one's saying that you should trust "blindly". Gotcha. Quick digression: I'm not a fan of the term 'trust on first use', as it can very reasonably be interpreted to mean exactly that. I mean, that's what is says... Wikipedia even gives it as one of its two almost antonymous definitions of the term, i.e. it can mean on first use, manually confirm whether to trust, or it can mean on first use, blindly trust. > The whole point of having a "hostile" warning when encountering a self-signed cert is protecting the user from impersonation attacks. There's a strong argument to be made that if you really want to protect the end-user from impersonation attacks, you shouldn't even give them the option of proceeding. Unfortunately, users are conditioned to click through warnings uncritically. > if you've established trust in other ways (such as by verifying the cert via an out-of-band channel, or because you set it up yourself) TOFU should be available In principle, sure, but what's the use-case here? We already have a secure, scalable, fool-proof solution to the problem: CAs. We insist upon CAs, because there's no good reason not to use them for all public-facing websites. What's the use-case here? If you want to run your own personal network, and your own personal alternative DNS scheme, you're free to set up your own personal CA for the purpose. Corporate networks do this. I see no reason to chuck out the whole concept of CAs. SSH is a different beast, as it's not intended for use by non-technical users. It's reasonable to insist on your sysadmin manually checking SSH fingerprints. Not so for non-technical users and HTTPS certs. Even in the case of SSH, CAs are a good solution if you're working at scale. To my knowledge, the only thing approaching a serious alternative to CAs, is web-of-trust, but it's not really a practical alternative.