12 votes

Topic deleted by author

10 comments

  1. [7]
    spit-evil-olive-tips
    Link
    That's correct. A "man-in-the-middle" between the user and the Tildes server, if TLS is enabled, should not be able to decrypt any traffic. They couldn't read the message, couldn't see that you...

    That's correct. A "man-in-the-middle" between the user and the Tildes server, if TLS is enabled, should not be able to decrypt any traffic. They couldn't read the message, couldn't see that you were the one who sent the message, and in fact shouldn't be able to tell that the user is looking at their messages at all compared to browsing the front page or a comment thread. They can probably tell that the user is browsing Tildes, based on one or both of a) unencrypted DNS queries or b) the IP of the server hosting tildes.net probably not being used to host many other websites.

    In Tildes' specific case, it goes a step further and enables connections only over TLS. You can test this out yourself:

    $ curl -v http://tildes.net
    *   Trying 2607:5300:203:2dd8:::80...
    * TCP_NODELAY set
    *   Trying 54.39.48.216:80...
    * TCP_NODELAY set
    * Connected to tildes.net (54.39.48.216) port 80 (#0)
    > GET / HTTP/1.1
    > Host: tildes.net
    > User-Agent: curl/7.65.3
    > Accept: */*
    > 
    * Mark bundle as not supporting multiuse
    < HTTP/1.1 301 Moved Permanently
    < Server: nginx
    < Date: Fri, 13 Mar 2020 23:34:27 GMT
    < Content-Type: text/html
    < Content-Length: 162
    < Connection: keep-alive
    < Location: https://tildes.net/
    < 
    
    12 votes
    1. Deimos
      Link Parent
      It's getting somewhat off-topic from the actual question, but I just wanted to mention that Tildes also uses HTTP Strict Transport Security (HSTS), which tells browsers that they should never be...
      • Exemplary

      It's getting somewhat off-topic from the actual question, but I just wanted to mention that Tildes also uses HTTP Strict Transport Security (HSTS), which tells browsers that they should never be willing to communicate with Tildes without using TLS. It's also on the HSTS preload list, which most major browsers use. Being on that list means that a browser knows it should never do any communication with Tildes without TLS, even before the user's ever visited the site. That ensures that even the very first request will be encrypted and it won't even try a non-HTTPS one.

      13 votes
    2. [6]
      Comment deleted by author
      Link Parent
      1. [3]
        Wes
        Link Parent
        No. TLS/SSL requires a certificate. Self-signed certificates exist, but do not carry the same level of trust as authority-signed certificates. It's not just about data leakage (although that's...

        Just because Tildes has TLS/SSL enabled does that mean that it is strong enough without the use of certificates?

        No. TLS/SSL requires a certificate. Self-signed certificates exist, but do not carry the same level of trust as authority-signed certificates.

        If most, if not all, users here are just sending conversation-style information back and forth to each other why would in-transit encryption matter? I mean I don't think anyone here would send a string of text that included their real name tied to their social security number and a credit card number.

        It's not just about data leakage (although that's important too). It's also about making it tamper-proof. By encrypting the content you know confidently that what other people are posting is genuine. It hasn't been modified by your ISP, or corporation, or anybody else in transit.

        This isn't theoretical either. Hotels and ISPs have been caught injecting ads or notices into pages. They can't do that with TLS.

        8 votes
        1. [2]
          vord
          Link Parent
          I think changing this would actually be more beneficial long term to de-centralizing the net a bit. Self-signed certs are certainly not inherently less secure, but there needs to be a good...

          Self-signed certificates exist, but do not carry the same level of trust as authority-signed certificates.

          I think changing this would actually be more beneficial long term to de-centralizing the net a bit. Self-signed certs are certainly not inherently less secure, but there needs to be a good mechanism for people to have a consensus of a genuine cert for a given site.

          Short of Let's Encrypt, most cert authorities are annoying and somewhat expensive.

          3 votes
          1. [2]
            Comment deleted by author
            Link Parent
            1. vord
              Link Parent
              Use Let's Encrypt. Given a choice, I'd use them over any other provider any day of the week. Gitlab (and Github, but I like Gitlab better) has Pages as well for hosting static content for free...

              Use Let's Encrypt. Given a choice, I'd use them over any other provider any day of the week. Gitlab (and Github, but I like Gitlab better) has Pages as well for hosting static content for free (like a front page for a FOSS project). You can also get a subdomain instead of a full domain initially to test things out for free.

              Assuming you can host dev instances yourself, that should reduce the need for any initial out of pocket costs.

              Links for the stuff I mentioned:
              https://letsencrypt.org/
              https://docs.gitlab.com/ee/user/project/pages/
              https://www.duckdns.org/

              7 votes
      2. Deimos
        Link Parent
        This is an entertaining presentation by Troy Hunt where he talks about why even sites where the user isn't sending any data should still be protected by HTTPS, I'd definitely recommend putting...

        This is an entertaining presentation by Troy Hunt where he talks about why even sites where the user isn't sending any data should still be protected by HTTPS, I'd definitely recommend putting aside 25 minutes to watch it: Here's Why Your Static Website Needs HTTPS

        There's a blog post along with it too that links to tons of other related articles and resources if you want to keep digging in to why it's important.

        7 votes
      3. chromakode
        (edited )
        Link Parent
        A "certificate" contains the public encryption key of the service which you use to establish an encrypted connection. TLS/SSL use the public key contained in the certificate. Importantly, the...
        1. A "certificate" contains the public encryption key of the service which you use to establish an encrypted connection. TLS/SSL use the public key contained in the certificate. Importantly, the certificate also contains a signature from another certificate that your browser trusts -- from a trusted "certificate authority" that attests that the certificate you have is the genuine one for the party it claims to be. Without that, a "man-in-the-middle" could substitute their own key so that they could read the data.

        2. +1 to everything @Wes said. I'd like to add that individual bits of data may seem innocuous, but having a large amount of data collected over time becomes much more dangerous. I'd recommend reading Maciej Ceglowski's talk about data as a toxic waste product to contextualize this. End-to-end encryption is a means of preventing third parties like network providers and governments from collecting large amounts of data.

        6 votes
  2. [3]
    chromakode
    Link
    You have the big picture correct, yes! A few detail nits. "Listening on a port" is a term used for server software registering with their operating system that incoming connections on that port...

    You have the big picture correct, yes! A few detail nits.

    "Listening on a port" is a term used for server software registering with their operating system that incoming connections on that port will be served by that program. You cannot "listen" to a port on another computer to intercept in-transit data. To intercept network packets from one device (not you) to another device (also not you), you will typically have to take additional actions, because most network environments only deliver you packets addressed to you. Some ways are being on the same physical network (getting electrical signals from hubbed connections), insecure WiFi (receiving transmissions), or being a "man in the middle" (network operator, VPN provider, government, or manipulating the routing of packets). Once you are able to intercept data, if it's not encrypted, then you will be able to view it (and read any private messages in the packet payloads).

    If the data is encrypted in transit (e.g. using TLS), then even if the packets are intercepted, parties other than the sender and recipient cannot read the data. This is known as end-to-end encryption. It's typically made possible by asymmetric encryption algorithms, so that you only need to receive a server's public key (and verify it) to begin sending data only the server can decrypt. Interceptors can sometimes still read metadata (like the IP address and port the packet was sent to), depending on the transport protocol.

    In practice, online services are not a black box, and consist of many smaller network services to carry out your requests. In some cases, your data will be sent unencrypted within the private network of the service provider. This is sometimes referred to as "TLS termination". So to be precise, your data is encrypted between your browser and the software which receives and decrypts it. What happens to it afterward (is it encrypted at rest? is it sent to other servers encrypted?) is up to the service.

    4 votes
    1. [3]
      Comment deleted by author
      Link Parent
      1. [2]
        chromakode
        Link Parent
        In theory, yes. In practice... it depends. Now we're in the realm of practice. Your server must implement a new enough version of TLS/SSL without known vulnerabilities (use a service like SSL Labs...

        So, if I enable TLS/SSL on a server instance then I should be all good as far as in-transit encryption?

        In theory, yes. In practice... it depends. Now we're in the realm of practice.

        Your server must implement a new enough version of TLS/SSL without known vulnerabilities (use a service like SSL Labs to check). The implementation of TLS/SSL must be correct. The underlying OS must also be free of defects (e.g. a predictable random number generator).

        You must keep the private key of your certificate safe. It will be stored on any servers terminating TLS/SSL connections. If someone gains access to one of those servers and reads the private key, they may be able to intercept and read encrypted data.

        Generally speaking, if you're using the latest patches of your OS and server software, and you've validated your TLS implementation using a checker, you're making a reasonable best effort to ensure your data is encrypted in-transit.

        6 votes
        1. [2]
          Comment deleted by author
          Link Parent
          1. chromakode
            (edited )
            Link Parent
            No problem. Also, these questions are never trivial. Perfectly securing user data is nearly impossible. Making a reasonable effort is a moral imperative, which is difficult because clever people...

            No problem. Also, these questions are never trivial. Perfectly securing user data is nearly impossible. Making a reasonable effort is a moral imperative, which is difficult because clever people are always trying to figure out flaws in the reasoning. It is absolutely worthwhile to ask these questions, re-ask them, and question any assumptions.

            5 votes