Announcement

Collapse
No announcement yet.

We need to make certs free and deprecate HTTP in favour of HTTPS with AES/TLS

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    I just don't want this guy monitoring my Internet.



    His government has committed to introducing the bill mentioned above, Bill C-51, into parliament within 100 days. His party has a majority, so he can do whatever he pleases, subject to internal party pressure.

    Are we going to be able to redesign HTTPS in less than 100 days? Hell no. BUT we can start a movement to *use* HTTPS to voluntarily encrypt almost Internet traffic using AES, TLS, and CAcert.

    We need to start now because if Harper gets away with Bill C-51, other countries will surely follow. It's best to be pre-emptive and encrypt now, rather than later.

    Comment


    • #12
      We need to work on getting everything encrypted. Then we need to move on to solving the CA problem. Perhaps we could replace SSL/TLS with OpenPGP combined with DNSSEC.

      Out of curiosity, what would the drawbacks of replacing SSL/TLS with OpenPGP combined with DNSSEC be?

      Comment


      • #13
        Everyone would need to install openpgp? lol

        Comment


        • #14
          Won't IPv6 do a much better job of "getting everything encrypted" than trying to get SSL/TLS/OpenPGP support into every Internet application? I can see why OpenPGP might still be useful for some applications (e.g. email, for which it was designed and which can involve multiple application-layer hops).

          As for DNSSEC, that's meant for protection against illegitimate DNS records; it won't do anything to protect your privacy.


          Originally posted by RealNC
          Very bright idea that one, make it impossible to use the one (encryption) without the other (identity verification). People who design this stuff are usually very intelligent, but when seeing things like that, you sometimes have to wonder...
          Without some form of identity verification, how do you tell the difference between a genuine encryption key and one injected by a MITM?

          Comment


          • #15
            Deprecate HTTP in favor of HTTPS, is this some kind of weird joke or something? Don't get me wrong, there is a strong need for increased use of encryption when using HTTP, but deprecating the unencrypted use is a waste of resources and somewhat unnecessary. There are a lot of use cases where encryption is downright pointless. There is no need to hide the fact that I'm reading an online newspaper, API documentation, a blog, forums (when I'm not logged in) or similar situations where no sensitive or otherwise protection-worthy information is exchanged. So why encrypt such traffic with HTTPS when:
            • you loose the possibility of caching between client and server
            • local caching behavior is not the same as for HTTP, i.e. browsers may not cache it on disk because of privacy issues doing so.
            • increased use of resources in both clients and especially servers. Having multiple servers serving the same site may require an SSL/TLS-terminator in front of those multiple servers for them to actually have decent performance.
            • increase latency, especially when establishing a new connection as you need to do handshakes etc.

            There is also a technical issue with HTTPS and name-based virtual hosting, that is it's not actually possible without something called Server Name Indication. SNI is not supported in older browsers. In the Windows-world IE6 don't support this and you need Vista and IE7 (no, IE7 + XP don't work here apparently). All in all, it just doesn't make any sense to fully deprecated HTTP.

            That said I don't disagree that there need to be more use of HTTPS. In fact, all sites with login should be somehow forced to use HTTPS, at least for the protected parts of it, as the user is transmitting a password he or she might be, with lack of understanding of security, using elsewhere as well. Logging in via a unencrypted network, such as a open WLAN, and HTTP has already been shown to compromise such people and the places they log into. However, currently this isn't possible since the certificates need to be bought in order for it to work properly. Hopefully CaCert might be a viable solution to resolve this in the future.

            Comment


            • #16
              We could get netpgp or GnuPG integrated into every web browser and webserver. Even through user-installable add-ons and modules, at first.




              -----

              Note: We should still use utilities like HTTPS Everywhere as any encryption is better than no encryption. However, we need to look to the future and form a plan to replace TLS/SSL as it is not suitable for universal web encryption.

              You no longer need HTTPS Everywhere to set HTTPS by default! Major browsers now offer native support for an HTTPS only mode. Learn how to turn it on. Read more about the sunset of HTTPS Everywhere.

              Comment


              • #17
                Originally posted by AHSauge View Post
                There are a lot of use cases where encryption is downright pointless. There is no need to hide the fact that I'm reading an online newspaper, API documentation, a blog, forums (when I'm not logged in) or similar situations where no sensitive or otherwise protection-worthy information is exchanged.
                Summary of this thread: Why is anything on the Internet in cleartext anymore?

                Originally posted by techophile at Ars Technica
                Encrypting all net communication would be a net (heh) good. There's no excuse for transmitting over cleartext in this day and age -- when you can turn on HTTPS in Facebook and Twitter, when FireSheep and its ilk are not only possible but actual, it's clear that everything you do online is important -- it's a matter of degree only.

                HTTPS is pretty fundamentally **** (because of the need for CAs, and the lack of any real oversight of CAs), but it's better than HTTP. Unfortunately there isn't really anyone who can push through unilateral type updates like that; if we get to encrypted-by-default it will be a slow, painful process.

                It needs to be done though; I just don't know how. As a software dev I'll tell you I will never again write a site or service that does not support encrypted comms, though -- HTTPS for now, whatever the better alternative is tomorrow.
                Seems like the tech community at large is strongly in favour of depreciating HTTP for HTTPS with AES/TLS. Like how we depreciated telnet and rsh for SSH a while back. Some useful utilities in light of Harper's new Internet Surveillance Law: HTTPS Everywhere (Firefox)...


                Also: http://canadianawareness.org/2011/05...new-bill-c-51/

                Comment


                • #18
                  Originally posted by Ex-Cyber View Post
                  Without some form of identity verification, how do you tell the difference between a genuine encryption key and one injected by a MITM?
                  Why would you need to know if the encryption key is genuine? The only one who needs to know is me. And, naturally, I do know, since I created it.

                  How do you trust your Linux system when you login to it through SSH?

                  Comment


                  • #19
                    Originally posted by RealNC View Post
                    Why would you need to know if the encryption key is genuine? The only one who needs to know is me. And, naturally, I do know, since I created it.

                    How do you trust your Linux system when you login to it through SSH?
                    That's what SSH Host Keys are for

                    ssh automatically maintains and checks a database containing identifica‐
                    tion for all hosts it has ever been used with. Host keys are stored in
                    ~/.ssh/known_hosts in the user's home directory. Additionally, the file
                    /etc/ssh/ssh_known_hosts is automatically checked for known hosts. Any
                    new hosts are automatically added to the user's file. If a host's iden‐
                    tification ever changes, ssh warns about this and disables password
                    authentication to prevent server spoofing or man-in-the-middle attacks,
                    which could otherwise be used to circumvent the encryption. The
                    StrictHostKeyChecking option can be used to control logins to machines
                    whose host key is not known or has changed.

                    Comment


                    • #20
                      Originally posted by locovaca View Post
                      That's what SSH Host Keys are for
                      Last time I checked, I didn't have to get my SSH host keys from a host key authority.

                      So if I want my site to use encryption, why does it matter who I am? It shouldn't. Unless I want it to matter and tell my visitors that it matters. And only in that case should the browser check whether I'm telling the truth. Otherwise, the browser shouldn't even bother displaying any kind of special "trusted connection" info/icon/whatever to the user. I should be able to make my site use encryption without claiming that it can be trusted, or even telling the visitors that the site uses encryption.

                      Comment

                      Working...
                      X