Yes, we also mean such domains.
I am thinking about the following scenario: if a country doesn’t want Internet Computer dapps, they can just block the *.ic0.app domains and no one in the country can access dapps on the IC. In this proposal, you want to add more domains, but countries can just block those as well right? Is there a way for the IC to make it accessible for everyone even if countries have the power to block certain domains?
Do you have any updates about how we can prevent malicious boundary nodes from serving modified responses, such as a tampered service worker?
Hi Gabe, we are looking into various ways to mitigate this. In fact we might provide multiple things to address this issue, because each measure has its own pros and cons. One direction is likely a web extension – here it can only be a point solution because the web extension needs substantial API support and for example Chrome likes to limit their extension APIs more and more. On the other side trusted execution is explored and we will amplify our efforts here during the next month. While trusted execution gives additional security it is not a silver bullet due to side-channel attacks that we have to take into account. Hope this helps a bit.
Hi, thank you for the answer. Do you mean a web extension as a replacement to the service worker acquired by boundary nodes? That sounds like a solution, but it takes away from the current seamless user experience on the IC. This should definitely not be underestimated in my opinion and may be one deciding factor for adoption.
I’m aware of the protection against intrusions at the host level that TEEs can bring, but do you care to explain how it can help ensure that e.g boundary nodes provide an unmodified response?
Why cant the BNs just have a replicated state that they come to consensus to and serve the SW from that state?
@JaMarco am not clear if consensus would solve the puzzle here. The replicas can propose, agree, and even sign the canonical version of the service worker. However, it still won’t stop the malicious boundary node from serving a corrupt service worker. I understand that such a tampered service worker won’t have the subnet signatures, but there is no abstraction/control point to check the signatures/authenticity of the service worker itself (in the browser)
Probably the signed service worker can be checked by the browser extension, (then again who would authenticate the extension)
How is this different than clients getting update responses from the IC? How are those results verified in the browser?
Hi, web extension will not be a replacement for the service worker - it is an alternative option for the security sensitive user that likes to have the browser experience but does not like to trust in the boundary node. The idea is that the web extension will work as a drop-in solution. If you have the extension the service worker will not be loaded – if you don’t have it the service worker will do the job. This way user experience should not be an issue.
Regarding trusted execution we aim to give the users means to validate via the browser and some additional easy tooling that she accesses a VM running on top of the right HW that executes the expected Boundary Node VM image. This includes the assumption that the HW is flawless and the attested code is correct – but we will take a rouge administrator out of the equation and exploits at the host os and hypervisor level.
The core problem is that a browser does not know about the APIv2 protocol of the IC. Thus in order to empower a clueless browser to speak to the IC, we let the browser contact the Boundary Node. The Boundary Node can now translate the ordinary HTTP request to a IC protocol conform request or return the IC service worker to the browser. The IC service worker enhances the browser to speak natively to the IC. If we would replicate the state at the Boundary Node level we run again into the problem that the browser is clueless on how to speak to a replicated system – in this case the Boundary Nodes.
By providing a web extension as @faraz.shaikh pointed out, we provide the knowlege on how to speak to the IC via a different path. (That in principle could be manipulated – however installing a web extension is a more explicit step and unlike a service worker that is frequently reloaded, a web extension needs to be updated. Thus, an explicit step, where a security sensitive user could take a closer look and inspect what is updated.)
Having the web extension as an alternative surely helps with the user experience/adoption points that I mentioned earlier. I think it is great to have extra tools for security sensitive users. However, we should face that if there is an easier path, i.e not using the extension, the majority of users will take that path. If 1/3 of users on IC installs the extension and 2/3 works with a less secure option as source of truth, then that can of course be really harmful for the ecosystem. And 1/3 is probably a very generous number in the context of mass adoption. Hence, it is more interesting to discuss the security aspects of the more common “path” in my opinion.
Can you explain in more detail how a user could validate a boundary node’s image to ensure that she is served an unmodified response? Also, what means exactly with the assumption that “the attested code is correct”?
Hi again, I fully agree with your approximation regarding the use of a web extension. However, the idea is to at least provide an alternative. Such a web extension might also be a crystallisation core for more projects in this direction such as making the ic protocol a native part of a browser.
Regarding the validation: The current direction that we evaluate is to secure the VMs via SEV-SNP (and later TDX maybe – see the other roadmap proposal) and empower users to perform remote attestation of the boundary node VM. If via remote attestation you can validate that only code that you trust in is running in the VM, the VM itself is protected via hardware mechanisms and that for the connection to the boundary node there is no way to establish a man-in-the-middle – this would be a big step forward.
How can you know what code is running in the VM? Well there needs to be a deterministic build process to create the boundary node image from the IC repository. You can inspect the code and see that nobody can get access to the VM once it is running. (No ssh access and no backdoor.) By repeating the build you gain a hash sum that should match with the one which is included in the remote attestation report. Of course, there is more to say how remote attestation exactly works but this might lead too far here.
The critical point of course as with any software that you (have to) trust in is that there could be bugs that can be exploited or there can be side channel attacks that might enable devoted attackers to circumvent the hardware protection.
Again you might ask, user experience?! The remote attestation will be again performed mainly by security sensitive users – via another web extension – or even a standalone tool. (In both cases the effective code will be very small and easy to validate and transfer.) In this case however the security-sensitive users will do something for the others. In case we have say only 10% of users doing remote attestation the likely hood of hosting a rogue boundary node is very limited to not get spotted. And the commodity users will benefit.
I appreciate the detailed answer, thank you.
Agreed. Solutions like this are important since, as you stated, everyday users will benefit from that as well.
Out of curiosity, have there been discussions of other strategies besides trusted execution?
Also, I understand that this is a complex problem that takes time to solve but do you have an answer to why this proposal is not prioritized more? The community interest seems low compared to other proposals. In my opinion, this might very well be the most critical part of the IC in its current state. IC’s edge over other blockchains is (among many other things) the ease of access from traditional clients, which is how the vast majority access it. If we don’t protect the network edge services then the rest of IC’s exceptional technology feels pointless, to some degree.
We have considered a number of options (such as the web extension and modifying the browser etc.). Is there a specific direction that you miss?
Well this problem has considerable priority and we are actively working on it. E.g., if you look into the ic repo you will find ic/ic-os/boundary-guestos which is a stepping stone for applying trusted execution.
Not really, I was just curious to hear other ideas.
Thanks again for providing more information regarding this. I am very keen to follow the progress.
I would love to hear about any updates regarding the boundary node decentralization effort, if there are any.
What is also clear is that BNs really need to obey the laws of the countries that they are physically located in(remember the nintendo episode?).
Therefore to a certain extent, the desire for them to be the same (i.e. same code running in each BN) , means that the embedding of which content can be legally served (or banned) through a specific BN must be embedded in the “template” of the BN.
Hi @rrkapitz, I have read in various places (e.g here) that boundary nodes can throttle interactions, e.g for DOS protection. Can you comment on if this is currently the case, and if so - can you provide some details?
For context, I am measuring the response time of entry points to a protocol I am developing and want to make many calls to then compute an average, standard deviation, etc. I want to make sure that I am not being throttled and thus getting a deceptive result. And IF I am likely being throttled, I want to know how long sleep time I need to add in between the function calls.
Just what I was looking for. Thank you for the response!