Closed kdenhartog closed 5 years ago
jakubkoci
commented
5 years ago In our team discussions about SSI use cases in relation to security, we very often end up with the necessity of HTTPS somewhere at a lower level. On top of that, I see strong affection to HTTPS in the web community around me. So I would agree with this requirement. Perhaps I would ask the opposite question if are there any disadvantages of requiring it?
dhh1128
commented
5 years ago I don't think we (the community) should "require" it. But I think we could recommend it as a best practice in the DIDComm best practices RFC (0074). When we recommend it, we should explain why. None of the web app attacks @kdenhartog listed seem like valid rationales to me; they don't have any difference in their behavior based on whether http or https is in use, do they? The rationale that I think does make sense is this: "Follow the principle-of-least-surprise. We don't really need https or care about any of its security, and we don't want people to rely on transport security as a crutch for sloppy thinking about protocol requirements. But we also don't want to have to argue with IT departments about why we don't need https. Besides, mobile apps cannot be listed on some app stores if they use plain http. It's easier just to use https so nobody raises their eyebrows."
kdenhartog
commented
5 years ago HTTPS will help in a few different ways here. For one the JS injection is prevented by HTTPS directly. The CSRF attack is introduced by the ability to MITM attack the server and change the HTML, and the XSS attacks are made much easier by the ability to inject JS. Troy Hunt has written a great blog post on how HTTPS helps prevent tons of problems on the web in this blog post.
Additionally, if we're going to say "The agent also exposes for the controller's exclusive use an HTTP API covering all of the administrative handlers for those events" we allude to the idea that everything on non-local agents can be controlled over a REST API. This will inevitably leave some developers thinking it's ok to embed some data in headers or URL parameters which don't explicitly mention must not be done.
Also, in order to secure the REST API from what I can tell the idea for the ACA-py is to use an API key. If an API key is being used, it will require the key to be exchanged securely in order to prevent sniffing of the API key.
In total, there's a lot of additional benefits to using HTTPS that are beneficial. While I think that the DIDComm cryptographic layer is beneficial, we need to use it in order to get its benefits. From what I can tell though, we aren't using DIDComm in Cloud agents to communicate between the controller and the cloud agent and therefore should require HTTPS be used.
dhh1128
commented
5 years ago Kyle, I went read the blog post you linked, and also watched a chunk of the demo video it provides. Thank you. There were some excellent and eye-opening learnings there. Wow.
However, I think the vulnerability of agents to this problem has some subtleties that don't transfer from Troy's discussion. When you cornify a web page or inject a Rick Roll or a javascript cryptominer into one because the traffic is insecure, you are depending on web browser features to pick up the malicious code. In other words, the maliciousness works because the software facilitating the interaction makes dangerous assumptions.
When an agent is using plain http, it is expecting the body of the request to contain an encrypted DIDComm envelope. A MITM could inject stuff, but it's going to be ignored, because an agent, not a browser, is parsing the payload. It cares nothing for hyperlinks and thus is immune to CSRFs. It isn't running javascript and thus will be unaffected by XSS. This means that most of what Troy demos is, I think, irrelevant to pure agent-to-agent communication.
That doesn't mean I think your recommendation is unnecessary. After watching Troy, I am convinced that you've identified an important issue. I just want to justify it with more careful verbiage. Pure DIDComm between non-browser agents is not susceptible to any of the issues Troy talks about. HOWEVER, if either agent is browser-based, all bets are off, because browsers make assumptions about how web-oriented the content of an HTTP request will be, and some browser behavior may execute independent of what the agent sees or needs. In those cases, everything that Troy talks about should be a concern.
In particular, I think your recommendation is a good one when people are building UIs or web-service+ajax-based interactions to control agents.
My suggestion is that we write a subdoc of the transports RFC that discusses https and transport-level security. It should link to Troy's excellent presentation, and we should make the point as carefully and powerfully as possible that using raw HTTP when browsers are involved is a bad idea.
kdenhartog
commented
5 years ago By and large I agree with your points about needing to make this required when a browser is being used. Take a look at the ephemeral challenge protocol though (which is intended to be used for A2A) and you'll see we're required to use the headers in the redirect flow because OAuth requires it (OAuth also requires HTTPS):
Does this change your take on whether we need to be using HTTPS for A2A as well?
dhh1128
commented
5 years ago I already had the opinion that we SHOULD be recommending HTTPS for A2A. The only question is how we justify that recommendation to others. You've provided several good reasons. I've pushed back on the blanket assertion that HTTP for A2A is insecure. Whether it is insecure or not depends on a number of subtleties that are not weaknesses of A2A.. Pure A2A over HTTP really can be secure without HTTPS--but there are enough caveats around how HTTP stacks work and interact with other standards like OAuth that we should recommend HTTPS anyway. Not by saying "A2A is insecure without HTTPS", but rather something like "HTTP is used in a number of contexts that introduce subtle considerations. Although it is possible to be secure with DIDComm+HTTP in some cases, it's safer and simpler to just use HTTPS in all situations where the two are combined."
On Wed, Jul 10, 2019 at 10:12 AM Kyle Den Hartog notifications@github.com wrote:
By and large I agree with your points about needing to make this required when a browser is being used. Take a look at the ephemeral challenge protocol though (which is intended to be used for A2A) and you'll see we're required to use the headers in the redirect flow because OAuth requires it (OAuth also requires HTTPS):
Does this change your take on whether we need to be using HTTPS for A2A as well?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/hyperledger/aries-rfcs/issues/97?email_source=notifications&email_token=AAQ3JCG6SA3EXWY6BKAMF4DP6YC47A5CNFSM4H2MN4OKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZT67GA#issuecomment-510128024, or mute the thread https://github.com/notifications/unsubscribe-auth/AAQ3JCFQHSS63XJ5RJVSL5DP6YC47ANCNFSM4H2MN4OA .
kdenhartog
commented
5 years ago "HTTP is used in a number of contexts that introduce subtle considerations. Although it is possible to be secure with DIDComm+HTTP in some cases, it's safer and simpler to just use HTTPS in all situations where the two are combined."
This is a perfect description in my opinion.
TelegramSam
commented
5 years ago Closed as discussed in Aries WG Call 2019-11-13
I was thinking about the implications of serving a UI over an HTTP endpoint and I think it opens up the possibility of a few Web app attacks like XSS, CSRFs, and JS injection. Should we be requiring agents that have Web App front ends run over HTTPS to prevent this?