3 ms·

There are many common software tasks that are just hard to do securely, and there is an incentive to keep it that way. Security is a huge industry mostly fille

There are many common software tasks that are just hard to do securely, and there is an incentive to keep it that way. Security is a huge industry mostly filled with people who check boxes and memorize obscure trivia. Consider TLS, the "industry standard" for connecting two processes securely over the network. There is a huge amount of complexity just to accomplish something that should be secure by default. Certificates, algorithms, cipher suites, domain names (for some reason). Cue the people who have traded some of their valuable time to memorize this trivia showing up to defend TLS and how simple it is. They remark that anyone who hasn't memorized this trivia "isn't a security expert". Contrast that to something like Wireguard. There are keys, one is private, and I swap the public ones. Simple as that. If the only way to connect two processes was to transfer a string `<public-key>@<ip address>` between them, think about how many problems would be avoided, and how many fewer security "experts" the industry would need.

MattPalmer1086 2y ago
Sure, now you just need a way to validate the public key and IP address genuinely belongs to the claimed identity. Could use a certificate?
- alphazard 2y ago
  The IP address is just a hint in that example because we don't yet have robust identity based networking. It's actually meaningless, either I successfully authenticate with the public key on the other end, or I don't. I don't care about getting the wrong IP address, worst thing that could happen is that I bother the wrong process and it can't establish a connection with me. You must be a TLS expert because saying we need to check if a public key "belongs to the claimed identity" is creating a problem where none exists. The public key is an identity, that's who I want to connect to. In the Wireguard example, it really is that easy.
  - abnry 2y ago
    I think man in the middle attacks are the concern. But still better than plaintext.
  - repelsteeltje 2y ago
    TLS (as in https for websites) solves a different trust issue than wireguard. The case you present was two trusted parties (or one party ) set up a VPN between two hosts. It assumes there is some pre existing secure channel to exchange the public keys. If you were to simply exchange those over telnet, you're open to mitm attacks. With https this key exchange mitm aspect is acknowledged and that is where most of the complexity comes in. Since a client typically connects to a website without prior keys, we need a trusted third party like a CA or trust chain to verify were connecting to the domain we intended to connect to. Not staying tls isn't bloated, but to be fair, it solves a more complicated problem.
    - alphazard 2y ago
      I don't think these use cases are as separable as the TLS "experts" would claim. If something is giving me the IP address, why can't it also give me the public key? We just don't have a convention of passing those things around together, security came after the fact. We didn't design for security. In a lot of cases the IP comes from a configuration file. That's assumed to be secure. In some cases it comes from an authority. If I'm trusting the authority for the IP address, why can't I trust them for the identity as well? I have to trust a different authority for that? That is twice as complicated as necessary. DNS should really be about which identity owns a name. We are starting to get there with DNSSec, once that's sorted out we could easily return `<public key>@<ip:port>` entries in authenticated DNS records. The root server (transitively) claimed that this public key represents this domain name, and it was last seen accepting connections at this IP and port.
      - tptacek 2y ago
        Purely from a technical perspective, whatever is giving you an IP address from a name lookup could indeed give you a certificate. The IETF has for 30 years been hypnotized by this fact, in much the same way as Joel Spolsky used to write about the "everything software project is some specific subclass of 'spreadsheet'". The problems with make name lookups yield certificates are all real-world, pragmatic, people-based issues: * The deployed base of DNS software, which includes middleboxes of all shapes and sizes that pay attention to DNS, is hostile to things that look like DANE lookups, so DANE lookups (really, all DNSSEC lookups) have a high failure rate, so high that anything using DNSSEC needs to have an alternate path to building a secure channel without DNSSEC. * The entities that ultimately decide what DNS lookups are going to return (note well: those entities are rarely ever the people who "own" the zones themselves) are themselves firms with roughly the same shape as certificate authorities, but with none of the accountability mechanisms; browser vendors had to force legacy CAs to adopt Certificate Transparency and no such leverage exists for the DNS. * For bonus fun, add in that ultimately most of the (~all of the popular) TLDs are de jure government controlled --- and governments have a lot of practice exploiting their control over DNS for policy ends. DNSSEC is a dead letter. Deployment in .COM actually WENT DOWN within the last 24 months, and it was trifling to begin with. The most common experience large tech companies have had with deploying it is "falling off the face of the Internet for several hours due to misconfiguration". Stick a fork in it. It was a reasonable idea that, like many reasonable ideas, has turned out to be completely impractical in the real world.
  - JackSlateur 2y ago
    The public key can be linked to an identity only if the client already own that mapping (identity <-> public key) For the vast majority of use cases, this cannot be done, hence certificates (with CA)
  - tptacek 2y ago
    WireGuard is deployed between mutually trusting, pre-introduced endpoints. TLS has to work for huge numbers of anonymous untrusting clients, often with transaction time budgets denominated in the tens of milliseconds. This is also where perennial exhortations to adopt SSH-style "ToFU" models on the public web run aground.
deleted 2y ago
[deleted]
imtringued 2y ago
The weirdest part about TLS is how a non standardized format (PEM) has become the defacto standard and is the leading cause of complexity in setting up TLS. Certbot doesn't support PKCS12, which is the actual standard format. So you have to put an extra step in-between certbot and your application.
Joker_vD 2y ago
Reminds me of homomorphically-encrypted cloud-computing efforts. Apparently, there is a fully functional, RISC-like virtual CPU (built out of Boolean gates) that C can compile to and that one can use for processing your secret data on untrusted machines [0]... and a very, very beefy Amazon instance can emulate it running at ~1 Hz clock. No, not 1 kHz. 1 Hz. At which point I just had to stop and re-evaluate the problem again. If I have such a small amount of data that I am find at processing it at single-digit IPS (micro-MIPSes? geez...) then surely I could just process it locally, and much faster (and cheaper to boot)? And if I have an amount of data large enough to warrant using cloud resources, and important enough to justify paying astronomical sums... surely I could just spend that kind of money to simply buy lots of hardware and, again, run it locally, and much faster (and cheaper to boot)? [0] https://arxiv.org/abs/2010.09410 https://arxiv.org/abs/2010.09410
Mountain_Skies 2y ago
>filled with people who check boxes That's why my switch from software development to application security only lasted four years. It drove me up the wall to find so many vulns and have them ignored because they weren't necessary to fix for the various compliance checklists to be completed. No one cared if systems were actually secured, they just cared that they got their compliance certified so if there ever were a breach, they'd have coverage for their liability. It's also an area where most people in it have little to no actual programming experience so when tools mark potential vulns, programmers can get away with claiming it's a false positive and everyone moves on, even if it's a plain as day case of clear text PII going out over the internet or some ancient injection vuln that no one wants to get their hands dirty fixing.
deleted 2y ago
[deleted]
rustcleaner 2y ago
Security should not be box checking. Security is seeing your cyber domain as territory you are militarily holding from the enemy. Security is understanding you're in a game of cyber spy vs spy with a globe of adversaries working to 'get' you. You can't checkbox this, it takes fluid, dynamic, multi-step thinking. In security, you are at constant war. It's not like being a Rent-A-Cop™ at the mall or bank, who is mainly a box checking scarecrow. Security is srs bidness.
dadrian 2y ago
What do you think secure by default means?
- alphazard 2y ago
  By secure I mean at least confidential, authenticated, and repudiable. So no one can read the data sent between A and B, B knows that it is communicating with A, and B cannot prove to anyone else that A sent particular data. There are more formal/rigorously defined terms for this and variations. You can google IND-CCA to start digging in. By default I mean that the least complicated, easiest to use, front-and-center API establishes this sort of connection with the 2nd party. And sending insecure data becomes akin to dealing with raw ethernet frames, possible, sometimes necessary, but not even allowed on most operating systems without elevated privileges. Concretely that might look like replacing `dial(host, port) -> Conn` functions with `dial(publicKey, host, port) -> SecureConn` functions.
  - dadrian 2y ago
    I'm confused as to why you think you can replace all the things in TLS that provide security with some sort of magical SecureConn function. TLS is the secure connection, so much so that your code example is exactly what happens in Golang when you use the TLS library. net.TLS provides a Dial() and a net.Conn implementation. Your argument seems to be "TLS is bad because it is complicated. We should replace it with something logically equivalent, but better in some way that I have not defined." This is a fundamentally unserious argument, unless you can say what is wrong and what the requirements for a new solution are that are not provided by TLS currently.
    - alphazard 2y ago
      Go write up the code to connect two parties. Just A and B. A knows about B and wants to connect to B specifically, B will talk to anyone, but wants to know exactly who. It's far more than just Serve and Dial, and often you have to involve a 3rd party, or know a lot of details about self-signed certificates and the particulars of authenticating them. If it was just Serve and Dial with the guarantees I mentioned, we would be in agreement that it was easy and a suitable default. > "TLS is bad because it is complicated. We should replace it with something logically equivalent, but better in some way that I have not defined." I thought I was fairly clear in saying: less complicated == better. That is the way in which it is better, that I am now defining explicitly for you. If that's controversial then that probably explains most your disagreement. The complexity has to be so low relative to other solutions that it is more likely to be used than not.

MattPalmer1086 2y ago

Sure, now you just need a way to validate the public key and IP address genuinely belongs to the claimed identity. Could use a certificate?

alphazard 2y ago
The IP address is just a hint in that example because we don't yet have robust identity based networking. It's actually meaningless, either I successfully authenticate with the public key on the other end, or I don't. I don't care about getting the wrong IP address, worst thing that could happen is that I bother the wrong process and it can't establish a connection with me. You must be a TLS expert because saying we need to check if a public key "belongs to the claimed identity" is creating a problem where none exists. The public key is an identity, that's who I want to connect to. In the Wireguard example, it really is that easy.
- abnry 2y ago
  I think man in the middle attacks are the concern. But still better than plaintext.
- repelsteeltje 2y ago
  TLS (as in https for websites) solves a different trust issue than wireguard. The case you present was two trusted parties (or one party ) set up a VPN between two hosts. It assumes there is some pre existing secure channel to exchange the public keys. If you were to simply exchange those over telnet, you're open to mitm attacks. With https this key exchange mitm aspect is acknowledged and that is where most of the complexity comes in. Since a client typically connects to a website without prior keys, we need a trusted third party like a CA or trust chain to verify were connecting to the domain we intended to connect to. Not staying tls isn't bloated, but to be fair, it solves a more complicated problem.
  - alphazard 2y ago
    I don't think these use cases are as separable as the TLS "experts" would claim. If something is giving me the IP address, why can't it also give me the public key? We just don't have a convention of passing those things around together, security came after the fact. We didn't design for security. In a lot of cases the IP comes from a configuration file. That's assumed to be secure. In some cases it comes from an authority. If I'm trusting the authority for the IP address, why can't I trust them for the identity as well? I have to trust a different authority for that? That is twice as complicated as necessary. DNS should really be about which identity owns a name. We are starting to get there with DNSSec, once that's sorted out we could easily return `<public key>@<ip:port>` entries in authenticated DNS records. The root server (transitively) claimed that this public key represents this domain name, and it was last seen accepting connections at this IP and port.
    - tptacek 2y ago
      Purely from a technical perspective, whatever is giving you an IP address from a name lookup could indeed give you a certificate. The IETF has for 30 years been hypnotized by this fact, in much the same way as Joel Spolsky used to write about the "everything software project is some specific subclass of 'spreadsheet'". The problems with make name lookups yield certificates are all real-world, pragmatic, people-based issues: * The deployed base of DNS software, which includes middleboxes of all shapes and sizes that pay attention to DNS, is hostile to things that look like DANE lookups, so DANE lookups (really, all DNSSEC lookups) have a high failure rate, so high that anything using DNSSEC needs to have an alternate path to building a secure channel without DNSSEC. * The entities that ultimately decide what DNS lookups are going to return (note well: those entities are rarely ever the people who "own" the zones themselves) are themselves firms with roughly the same shape as certificate authorities, but with none of the accountability mechanisms; browser vendors had to force legacy CAs to adopt Certificate Transparency and no such leverage exists for the DNS. * For bonus fun, add in that ultimately most of the (~all of the popular) TLDs are de jure government controlled --- and governments have a lot of practice exploiting their control over DNS for policy ends. DNSSEC is a dead letter. Deployment in .COM actually WENT DOWN within the last 24 months, and it was trifling to begin with. The most common experience large tech companies have had with deploying it is "falling off the face of the Internet for several hours due to misconfiguration". Stick a fork in it. It was a reasonable idea that, like many reasonable ideas, has turned out to be completely impractical in the real world.
- JackSlateur 2y ago
  The public key can be linked to an identity only if the client already own that mapping (identity <-> public key) For the vast majority of use cases, this cannot be done, hence certificates (with CA)
- tptacek 2y ago
  WireGuard is deployed between mutually trusting, pre-introduced endpoints. TLS has to work for huge numbers of anonymous untrusting clients, often with transaction time budgets denominated in the tens of milliseconds. This is also where perennial exhortations to adopt SSH-style "ToFU" models on the public web run aground.

deleted 2y ago

[deleted]

imtringued 2y ago

The weirdest part about TLS is how a non standardized format (PEM) has become the defacto standard and is the leading cause of complexity in setting up TLS. Certbot doesn't support PKCS12, which is the actual standard format. So you have to put an extra step in-between certbot and your application.

Joker_vD 2y ago

Reminds me of homomorphically-encrypted cloud-computing efforts. Apparently, there is a fully functional, RISC-like virtual CPU (built out of Boolean gates) that C can compile to and that one can use for processing your secret data on untrusted machines [0]... and a very, very beefy Amazon instance can emulate it running at ~1 Hz clock. No, not 1 kHz. 1 Hz. At which point I just had to stop and re-evaluate the problem again. If I have such a small amount of data that I am find at processing it at single-digit IPS (micro-MIPSes? geez...) then surely I could just process it locally, and much faster (and cheaper to boot)? And if I have an amount of data large enough to warrant using cloud resources, and important enough to justify paying astronomical sums... surely I could just spend that kind of money to simply buy lots of hardware and, again, run it locally, and much faster (and cheaper to boot)? [0] https://arxiv.org/abs/2010.09410 https://arxiv.org/abs/2010.09410

Mountain_Skies 2y ago

>filled with people who check boxes That's why my switch from software development to application security only lasted four years. It drove me up the wall to find so many vulns and have them ignored because they weren't necessary to fix for the various compliance checklists to be completed. No one cared if systems were actually secured, they just cared that they got their compliance certified so if there ever were a breach, they'd have coverage for their liability. It's also an area where most people in it have little to no actual programming experience so when tools mark potential vulns, programmers can get away with claiming it's a false positive and everyone moves on, even if it's a plain as day case of clear text PII going out over the internet or some ancient injection vuln that no one wants to get their hands dirty fixing.

deleted 2y ago

[deleted]

rustcleaner 2y ago

Security should not be box checking. Security is seeing your cyber domain as territory you are militarily holding from the enemy. Security is understanding you're in a game of cyber spy vs spy with a globe of adversaries working to 'get' you. You can't checkbox this, it takes fluid, dynamic, multi-step thinking. In security, you are at constant war. It's not like being a Rent-A-Cop™ at the mall or bank, who is mainly a box checking scarecrow. Security is srs bidness.

dadrian 2y ago

What do you think secure by default means?

alphazard 2y ago
By secure I mean at least confidential, authenticated, and repudiable. So no one can read the data sent between A and B, B knows that it is communicating with A, and B cannot prove to anyone else that A sent particular data. There are more formal/rigorously defined terms for this and variations. You can google IND-CCA to start digging in. By default I mean that the least complicated, easiest to use, front-and-center API establishes this sort of connection with the 2nd party. And sending insecure data becomes akin to dealing with raw ethernet frames, possible, sometimes necessary, but not even allowed on most operating systems without elevated privileges. Concretely that might look like replacing `dial(host, port) -> Conn` functions with `dial(publicKey, host, port) -> SecureConn` functions.
- dadrian 2y ago
  I'm confused as to why you think you can replace all the things in TLS that provide security with some sort of magical SecureConn function. TLS is the secure connection, so much so that your code example is exactly what happens in Golang when you use the TLS library. net.TLS provides a Dial() and a net.Conn implementation. Your argument seems to be "TLS is bad because it is complicated. We should replace it with something logically equivalent, but better in some way that I have not defined." This is a fundamentally unserious argument, unless you can say what is wrong and what the requirements for a new solution are that are not provided by TLS currently.
  - alphazard 2y ago
    Go write up the code to connect two parties. Just A and B. A knows about B and wants to connect to B specifically, B will talk to anyone, but wants to know exactly who. It's far more than just Serve and Dial, and often you have to involve a 3rd party, or know a lot of details about self-signed certificates and the particulars of authenticating them. If it was just Serve and Dial with the guarantees I mentioned, we would be in agreement that it was easy and a suitable default. > "TLS is bad because it is complicated. We should replace it with something logically equivalent, but better in some way that I have not defined." I thought I was fairly clear in saying: less complicated == better. That is the way in which it is better, that I am now defining explicitly for you. If that's controversial then that probably explains most your disagreement. The complexity has to be so low relative to other solutions that it is more likely to be used than not.