Timeline for Securing REST API without HTTPS
Current License: CC BY-SA 3.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 13, 2017 at 12:48 | history | edited | CommunityBot |
replaced http://crypto.stackexchange.com/ with https://crypto.stackexchange.com/
|
|
| Jul 12, 2015 at 17:48 | comment | added | ieatpizza | In regards to MITM - look at what the NSA wanted to try to do with Lavabit. | |
| Jul 12, 2015 at 17:46 | comment | added | ieatpizza | I can't eavesdrop on you if you're literally physically transporting the secret on a piece of paper, USB thumbdrive. Also, if the attacker has enough access to your client to get this secret, he probably has enough access to get a private key off of the same client. | |
| Jul 12, 2015 at 14:27 | comment | added | Aaron D | I understand that to completely prevent any attack some PKI with HTTPS is required, but I feel asymmetric keys at least make long-term impersonation impractical without being discovered, at least, which I feel is not something that can be accomplished with shared secrets. | |
| Jul 12, 2015 at 14:21 | comment | added | Aaron D | You make some good points. The only thing I can think of is that to do that would require a complete MITM attack (spoofing the entire server and maintaining it long-term to prevent the attack from being discovered), while a shared secret only has to be intercepted once by an eavesdropper and can be used forever thereafter. | |
| Jul 12, 2015 at 8:21 | comment | added | ieatpizza | Think about it - what's stopping a potential attacker from intercepting your public key, and just replacing it with their own? | |
| Jul 12, 2015 at 8:20 | comment | added | ieatpizza | So instead of transporting it over the network, why wouldn't you be able to transport it some other way - eg, writing it on a piece of paper and manually typing it in to a config file?If your network is completely untrusted, and it's completely impossible to have any type of trusted PKI, with no pre-shared secret, what you described would be impossible. | |
| Jul 11, 2015 at 17:20 | comment | added | Aaron D | The problem is that the API key's secret has to be transported over the network at least once (either from the client to the server, or the server to the client). Since it's plain HTTP, an attacker could intercept it at that point and impersonate the client. Would sending only a public key from the client to the server avoid this? Can I use a public key to verify that client messages are authentic? Obviously a MITM attack owns the key exchange (fake server impersonation), but I think that weakness is unavoidable without HTTPS. | |
| Jul 11, 2015 at 16:06 | review | First posts | |||
| Jul 11, 2015 at 16:12 | |||||
| Jul 11, 2015 at 16:04 | history | answered | ieatpizza | CC BY-SA 3.0 |