3 ms·

At least for local development, disable the cipher suites with a DH key exchange and configure wireshark to use the private key.

codedokode 8y ago
So inconvenient.
- ygjb 8y ago
  Security engineers around the world have been working for decades to clean up the mess made by engineers, product designers, and business owners overlooking security because it's inconvenient. If you are a developer or engineer then eat the complexity tax as part of your responsibility and ensure that you are shipping code and products that are secure for the end user who probably doesn't have the expertise to overcome the security gaps left by "developer inconvenience".
  - tracker1 8y ago
    Or, you know, abstract the application layer and then apply the TLS layer on top of it so that it can be secured, but not effect the application code/logic.
    - Klathmon 8y ago
      To be fair, that's been tried a lot, and it keeps causing issues. I'm at the point where I believe that you can't "layer on" or "abstract away" security like you can with other things, it needs to be thought about at every step. Just look at attacks that can take advantage of content-length to pluck out which page the user is requesting of a mostly-static site, or how compression and encryption seem to almost be at odds with one another. You can't ever just assume TLS will handle it when it's abstracted away, and while HTTP/3 may not get rid of those kinds of attacks entirely, bringing "security" closer to the application logic may enable better protections.
      - tracker1 8y ago
        Possibly... I'm just concerned about yet another layer to have to be far more concerned about than I already am. I really enjoy building applications. I'm pretty good at systems and orchestration to an extent, but would rather not have to focus too much. Going from using an application framework that's more abstracted, such as ASP.Net (not mvc/api/core) to those where you are closer to the metal (node, python, .net core/mvc/api) was a jump. Thinking in terms of leveraging push with HTTP/2 alone has me concerned. The tooling around building web applications hasn't even caught up to the current state of being, let alone moving farther. Another issue is dealing with certificates against local/internal development in smaller organizations. It may get interesting, and it may get more interesting than it's actually worth in some regards.
kevin_thibedeau 8y ago
The world is moving to ECDHE which makes this less trivial.
- tialaramex 8y ago
  In a Diffie Hellman setup, configure the machine you aren't sat in front of (usually the server) to use a fixed secret value instead of a random one. Now since you know this value, and the other value you need (from the client in this case) is sent over the wire, you can run the DH algorithm and decrypt everything. You should (obviously) never do this in production, although it is what various financial institutions plan to do and they have standardised at ETSI as an "improvement" on TLS (you know, like how TSA locks are an "improvement" over actually locking your luggage so random airport staff can't steal stuff) ...
  - justincormack 8y ago
    TSA locks are an improvement over having your lock broken off, not vs it remaining locked. Using a fixed ephemeral on the other hand is going to happen in prod too...
- petronio 8y ago
  Are they disabling suites that don't use DH exchanges on the clients? Maybe I'm behind, but I can't imagine that happening on any major client.
  - deleted 8y ago
    [deleted]

codedokode 8y ago

So inconvenient.

ygjb 8y ago
Security engineers around the world have been working for decades to clean up the mess made by engineers, product designers, and business owners overlooking security because it's inconvenient. If you are a developer or engineer then eat the complexity tax as part of your responsibility and ensure that you are shipping code and products that are secure for the end user who probably doesn't have the expertise to overcome the security gaps left by "developer inconvenience".
- tracker1 8y ago
  Or, you know, abstract the application layer and then apply the TLS layer on top of it so that it can be secured, but not effect the application code/logic.
  - Klathmon 8y ago
    To be fair, that's been tried a lot, and it keeps causing issues. I'm at the point where I believe that you can't "layer on" or "abstract away" security like you can with other things, it needs to be thought about at every step. Just look at attacks that can take advantage of content-length to pluck out which page the user is requesting of a mostly-static site, or how compression and encryption seem to almost be at odds with one another. You can't ever just assume TLS will handle it when it's abstracted away, and while HTTP/3 may not get rid of those kinds of attacks entirely, bringing "security" closer to the application logic may enable better protections.
    - tracker1 8y ago
      Possibly... I'm just concerned about yet another layer to have to be far more concerned about than I already am. I really enjoy building applications. I'm pretty good at systems and orchestration to an extent, but would rather not have to focus too much. Going from using an application framework that's more abstracted, such as ASP.Net (not mvc/api/core) to those where you are closer to the metal (node, python, .net core/mvc/api) was a jump. Thinking in terms of leveraging push with HTTP/2 alone has me concerned. The tooling around building web applications hasn't even caught up to the current state of being, let alone moving farther. Another issue is dealing with certificates against local/internal development in smaller organizations. It may get interesting, and it may get more interesting than it's actually worth in some regards.

kevin_thibedeau 8y ago

The world is moving to ECDHE which makes this less trivial.

tialaramex 8y ago
In a Diffie Hellman setup, configure the machine you aren't sat in front of (usually the server) to use a fixed secret value instead of a random one. Now since you know this value, and the other value you need (from the client in this case) is sent over the wire, you can run the DH algorithm and decrypt everything. You should (obviously) never do this in production, although it is what various financial institutions plan to do and they have standardised at ETSI as an "improvement" on TLS (you know, like how TSA locks are an "improvement" over actually locking your luggage so random airport staff can't steal stuff) ...
- justincormack 8y ago
  TSA locks are an improvement over having your lock broken off, not vs it remaining locked. Using a fixed ephemeral on the other hand is going to happen in prod too...
petronio 8y ago
Are they disabling suites that don't use DH exchanges on the clients? Maybe I'm behind, but I can't imagine that happening on any major client.
- deleted 8y ago
  [deleted]