Timeline for A tale of two sources: Is TLS *defense* against Man-in-the-Middle, or not?
Current License: CC BY-SA 3.0
16 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 20, 2017 at 4:09 | comment | added | David Schwartz | @deviantfan Consider two systems. In the first, the message is encrypted by the sender with the recipient's public key. In the second, the message is relayed by several machines (think SMTP) and each link uses transport encryption. Which is more secure? Transport security protects each hop and is only secure if some overlay scheme ensures that the hops are all trusted. Message security only requires you to know a public key known only to the recipient or to share a secret key and is invulnerable to MITMs if symmetric. | |
| Jan 19, 2017 at 22:45 | comment | added | user | @Joshua Heartbleed relied on software bugs (specifically, improper bounds checking) to exfiltrate data. It was made possible by the fact that TLS includes the heartbeat feature, but it became a problem because of software bugs. If the software had been implemented correctly, then having the heartbeat feature in TLS would not have enabled the heartbleed attack. Sure the same thing could be said for a lot of security-related issues, but let's put in this case blame where blame is due: Heartbleed was not a result of a TLS problem, but an implementation problem. | |
| Jan 19, 2017 at 21:30 | comment | added | Joshua | @Azteca: Of those you list, only Heartbleed was really usable against an HTTPS application other than a browser. | |
| Jan 19, 2017 at 17:58 | comment | added | Ajedi32 | @DaveSwersky Yes, assuming the application is using TLS correctly (Which may or may not be the case for WCF. Again, I don't know.) then yes, it will protect against MITM attacks. | |
| Jan 19, 2017 at 17:53 | comment | added | Dave Swersky | @Ajedi32 OK, so the "properly configured" caveat is the real point of contention? All things being equal: TLS is set up correctly and all public CA certs are present and used properly, TLS is the way to prevent MITM? | |
| Jan 19, 2017 at 17:48 | comment | added | Ajedi32 | @DaveSwersky Think of it this way. If I use HTTPS to connect to a server, but I accept any TLS certificate as valid regardless of whether or not it's signed by a trusted CA (no major browsers actually do this, I'm just using it as an example), I'm still vulnerable to MITM even though I'm technically "using" TLS. So if WCF uses TLS that way, then its implementation of TLS would be insecure. (I'm not saying it does, like I said I know nothing about WCF.) This would not mean however that TLS is "insecure", just WCF's implementation of it. | |
| Jan 19, 2017 at 17:40 | comment | added | Dave Swersky | @Ajedi32 AFAIK, TLS works the same way for WCF as any other data- by definition, transport-layer security is data-agnostic. I can't think of a way the behavior of TLS would be different for WCF than for any other data-level protocol (REST/JSON for example.) | |
| Jan 19, 2017 at 17:38 | comment | added | Ajedi32 | Are you sure "the disadvantage is that this kind of security is applied separately on each hop in the communication path" isn't true in the context of WCF? Maybe WCF's implementation of TLS requires that things are done that way. (I don't know, I'm not familiar with WCF.) | |
| Jan 19, 2017 at 17:22 | comment | added | deviantfan | @DaveSwersky Right. The kind of transmitted data doesn't matter. | |
| Jan 19, 2017 at 17:18 | comment | added | Dave Swersky | @deviantfan That matches with the other research we've found. For context- this is a call to a webservice, not a public site. No browsers involved. I don't think that really changes anything overall, does it? | |
| Jan 19, 2017 at 17:15 | comment | added | deviantfan | @Azteca Let's say, HTTPS with the newest TLS version and proper configuration. And parts of the problems are not TLS problems, but bugs in specific programs working with TLS. | |
| Jan 19, 2017 at 17:15 | comment | added | Dave Swersky | @Azteca We're not asserting that TLS is unbreakable, just trying to reconcile the claim from HP against other research that indicates it is the favored protection against MITM. | |
| Jan 19, 2017 at 17:14 | comment | added | deviantfan | @DaveSwersky To start with, in a HTTPS setup, the server has a private key (in a certificate). Because of that, you can click on a lock symbol in the browser and see a CA guarantee that the website comes from server X. With hop2hop, all you could get is a guarantee that the data comes from your router at home. The web server is the only entity with the right and signed key for this website. | |
| Jan 19, 2017 at 17:13 | comment | added | Azteca | You sure HTTPS is secure? What about Heartbleed? POODLE attack? SSLStrip? | |
| Jan 19, 2017 at 17:11 | comment | added | Dave Swersky | That's the part in the HP article that didn't ring true for us. Doesn't seem to jive with all other research. | |
| Jan 19, 2017 at 17:09 | history | answered | deviantfan | CC BY-SA 3.0 |