3 ms·

What's the advantage (I can't see any) of this scheme over using client certificates where appropriate? It seems to me that the "attestation" doesn't add anyth

What's the advantage (I can't see any) of this scheme over using client certificates where appropriate? It seems to me that the "attestation" doesn't add anything (other than the ability to positively identify a device across multiple sites, which is a downside rather than an advantage) to the TLS session set up process. If a site (i.e., a corporate VPN) needs to ensure that a particular client is authorized to access it, client certificates and user authentication already provide such confirmation. I don't see why this is necessary for sites that, while they may wish to encrypt sessions with TLS, don't have any reason to track (and potentially block) devices that don't possess the properties (e.g., no ad blocker) they want to see. ISTM that this is antithetical to the peer-to-peer nature of the Internet and is just another way to restrict access for those who are deemed to be acting against the financial interests of large corporations. I have no interest in donating my CPU cycles and bandwidth to those who want to identify/categorize/advertise/restrict my access to the open internet. This could also kill off tools like curl, yt-dlp and other non-browser tools. Altogether a terrible idea. Or am I missing something important?

xenocratus 3y ago
> Or am I missing something important? The fact that the internet != traffic going to your laptop/PC/phone. There are a lot of non-consumer use-cases (think, processing of corporate data in the cloud, or deployment of industrial IoT devices) where you want very strong guarantees about the state of the entity you're talking to, stronger than a static x509 gives you. > over using client certificates The use-cases are also not restricted to client authentication (and "client" doesn't always mean outside of the cloud).
- nobody9999 3y ago
  >The fact that the internet != traffic going to your laptop/PC/phone. >There are a lot of non-consumer use-cases (think, processing of corporate data in the cloud, or deployment of industrial IoT devices) where you want very strong guarantees about the state of the entity you're talking to, stronger than a static x509 gives you. I am aware that the Internet is not limited to websites and personal devices. In fact, I have implemented/secured/managed corporate networks with multiple secured data channels (both within the organization and its employees and in B2B and B2C contexts) many times. Securing such data (whether within a cloud infrastructure or across the open internet) streams doesn't require such remote "attestation." In fact, it adds an additional layer of complexity that, at least AFAICT, primarily adds the ability to track personal devices and usage across the wider internet. >> over using client certificates >The use-cases are also not restricted to client authentication (and "client" doesn't always mean outside of the cloud). Fair enough. call such certificates whatever you like. However in the corporate context, I'd much prefer to be able to verify authorized connections via a process within my control (e.g., issuing my own certificates to network-based devices, servers/VMs/containers/whatever) rather than relying upon some third-party (whether that's an SGX store or a remote "attestation" authority) for such authentication/authorization processes. I'll add that this (and by me, repeatedly, as well as many thousands of others) has been successfully accomplished without building a mechanism to uniquely identify arbitrary (as opposed to specific devices involved in sharing data streams) devices on the 'net. Which is, AFAICT, what this Internet Draft appears to be advocating.
CHY872 3y ago
These APIs can be combined quite nicely with 'secure enclave' processing technologies like Intel SGX. The idea is that (at the very least) a processor can attest that the process communicating with your server is an unmodified copy of your binary. A further version might be that the data associated with that process remains encrypted and other processes are unable to read it. Apparently it mostly works! But as is usual with modern processors, there are many side channels. This has some cool use cases! For example, Microsoft SQL server can already use SGX to implement additional data security. A user can run sql queries including pushdown filters on data the administrator of the server can never access, because certain columns of the data is encrypted and never held unencrypted in memory. If you're at a tech company and have ever worried about rogue administrators accessing the data of your users, these enclaves are great for that (in theory)! Right now, people have to build their own transport layers, which interact with the attestation APIs. These folks are trying to build something that is as easy to set up as TLS. A problem with all this tech is that to the extent it can be used to make business problems easier to solve, it makes it much harder to introspect what running software is doing, which from a software freedom perspective tends to raise hackles. My hope would be that in general, this is more used like 'corporate TLS interception' insofar as your personal device does not do it, but I'd expect that mobile device vendors use it before too long.
- nobody9999 3y ago
  >A problem with all this tech is that to the extent it can be used to make business problems easier to solve, it makes it much harder to introspect what running software is doing, which from a software freedom perspective tends to raise hackles. My hope would be that in general, this is more used like 'corporate TLS interception' insofar as your personal device does not do it, but I'd expect that mobile device vendors use it before too long. A fair point. Although, given that corporate environments have been doing this sort of thing securely (in a variety of contexts beyond just browsing) for a long time without such remote "attestation," I'm skeptical that this provides much value other than for tracking/spying.
bobbiechen 3y ago
(Disclosure: I work at Anjuna, a member of the Confidential Computing Consortium. Opinions my own.) The value of remote attestation in general (setting aside the implementation detail of RA-TLS) is that you have a form of software identity which is tied directly to the exact code that you're running. For example, if someone steals your service's API key, token, or cert, then they can impersonate your service. But if you are using remote attestation, they will not be able to generate the proper "credential" (a hardware-backed attestation document) to do it. Here on HN lately, I've seen a lot of focus on end user devices for things like Web Integrity. But at work I'm seeing mainly customer use cases which are purely internal and server-side - think reducing risk of insider threats, or simplifying cert management with SPIFFE/SPIRE. For some more publicly-visible use cases, MobileCoin's Fog system https://mobilecoin.com/learn/fog https://mobilecoin.com/learn/fog use remote attestation to ensure validator nodes are coordinating using the same code (rather than some malicious version). Or for a non-blockchain use case, Dashlane's Confidential SSO https://www.dashlane.com/blog/streamline-logins-dashlane-confidential-sso https://www.dashlane.com/blog/streamline-logins-dashlane-con... uses remote attestation so that encryption keys can only be accessed by approved code - reducing risk from insider threats. I just wrote a blog post on another use case we are beginning to see: truly verifiable services. Say you want to operate a managed instance of an open-source project, to save users the operational hassle. How would a user know you're really running that OSS project, rather than a malicious version that steals their data? Using remote attestation, you can actually prove that: https://www.anjuna.io/blog/remote-attestation-enhancing-identity-with-confidential-computing https://www.anjuna.io/blog/remote-attestation-enhancing-iden...
- nobody9999 3y ago
  >The value of remote attestation in general (setting aside the implementation detail of RA-TLS) is that you have a form of software identity which is tied directly to the exact code that you're running. For example, if someone steals your service's API key, token, or cert, then they can impersonate your service. But if you are using remote attestation, they will not be able to generate the proper "credential" (a hardware-backed attestation document) to do it. That's an excellent point and I agree it's important to ensure strong authentication/authorization for such applications. However, as suggested in the Internet Draft, this would go far beyond simply ensuring that a specific peer is authorized to access another specific peer. Rather, it would essentially assign (based on keys, presumably in a secure enclave) a globally unique identifier that can then be tracked across the entire internet, rather than just ensuring that a particular set of peers are authorized to securely communicate. This is not a new issue and, for the most part, is a solved problem that absolutely does not require that arbitrary devices be permanently fingerprinted/identified. I'm sure that many folks may disagree, especially since "remote attestation" is the new shiny, but that doesn't mean there aren't perfectly functional methods already in use that provide similar functionality -- without the potential for spying/tracking.

xenocratus 3y ago

> Or am I missing something important? The fact that the internet != traffic going to your laptop/PC/phone. There are a lot of non-consumer use-cases (think, processing of corporate data in the cloud, or deployment of industrial IoT devices) where you want very strong guarantees about the state of the entity you're talking to, stronger than a static x509 gives you. > over using client certificates The use-cases are also not restricted to client authentication (and "client" doesn't always mean outside of the cloud).

nobody9999 3y ago
>The fact that the internet != traffic going to your laptop/PC/phone. >There are a lot of non-consumer use-cases (think, processing of corporate data in the cloud, or deployment of industrial IoT devices) where you want very strong guarantees about the state of the entity you're talking to, stronger than a static x509 gives you. I am aware that the Internet is not limited to websites and personal devices. In fact, I have implemented/secured/managed corporate networks with multiple secured data channels (both within the organization and its employees and in B2B and B2C contexts) many times. Securing such data (whether within a cloud infrastructure or across the open internet) streams doesn't require such remote "attestation." In fact, it adds an additional layer of complexity that, at least AFAICT, primarily adds the ability to track personal devices and usage across the wider internet. >> over using client certificates >The use-cases are also not restricted to client authentication (and "client" doesn't always mean outside of the cloud). Fair enough. call such certificates whatever you like. However in the corporate context, I'd much prefer to be able to verify authorized connections via a process within my control (e.g., issuing my own certificates to network-based devices, servers/VMs/containers/whatever) rather than relying upon some third-party (whether that's an SGX store or a remote "attestation" authority) for such authentication/authorization processes. I'll add that this (and by me, repeatedly, as well as many thousands of others) has been successfully accomplished without building a mechanism to uniquely identify arbitrary (as opposed to specific devices involved in sharing data streams) devices on the 'net. Which is, AFAICT, what this Internet Draft appears to be advocating.

CHY872 3y ago

These APIs can be combined quite nicely with 'secure enclave' processing technologies like Intel SGX. The idea is that (at the very least) a processor can attest that the process communicating with your server is an unmodified copy of your binary. A further version might be that the data associated with that process remains encrypted and other processes are unable to read it. Apparently it mostly works! But as is usual with modern processors, there are many side channels. This has some cool use cases! For example, Microsoft SQL server can already use SGX to implement additional data security. A user can run sql queries including pushdown filters on data the administrator of the server can never access, because certain columns of the data is encrypted and never held unencrypted in memory. If you're at a tech company and have ever worried about rogue administrators accessing the data of your users, these enclaves are great for that (in theory)! Right now, people have to build their own transport layers, which interact with the attestation APIs. These folks are trying to build something that is as easy to set up as TLS. A problem with all this tech is that to the extent it can be used to make business problems easier to solve, it makes it much harder to introspect what running software is doing, which from a software freedom perspective tends to raise hackles. My hope would be that in general, this is more used like 'corporate TLS interception' insofar as your personal device does not do it, but I'd expect that mobile device vendors use it before too long.

nobody9999 3y ago
>A problem with all this tech is that to the extent it can be used to make business problems easier to solve, it makes it much harder to introspect what running software is doing, which from a software freedom perspective tends to raise hackles. My hope would be that in general, this is more used like 'corporate TLS interception' insofar as your personal device does not do it, but I'd expect that mobile device vendors use it before too long. A fair point. Although, given that corporate environments have been doing this sort of thing securely (in a variety of contexts beyond just browsing) for a long time without such remote "attestation," I'm skeptical that this provides much value other than for tracking/spying.

bobbiechen 3y ago

(Disclosure: I work at Anjuna, a member of the Confidential Computing Consortium. Opinions my own.) The value of remote attestation in general (setting aside the implementation detail of RA-TLS) is that you have a form of software identity which is tied directly to the exact code that you're running. For example, if someone steals your service's API key, token, or cert, then they can impersonate your service. But if you are using remote attestation, they will not be able to generate the proper "credential" (a hardware-backed attestation document) to do it. Here on HN lately, I've seen a lot of focus on end user devices for things like Web Integrity. But at work I'm seeing mainly customer use cases which are purely internal and server-side - think reducing risk of insider threats, or simplifying cert management with SPIFFE/SPIRE. For some more publicly-visible use cases, MobileCoin's Fog system https://mobilecoin.com/learn/fog https://mobilecoin.com/learn/fog use remote attestation to ensure validator nodes are coordinating using the same code (rather than some malicious version). Or for a non-blockchain use case, Dashlane's Confidential SSO https://www.dashlane.com/blog/streamline-logins-dashlane-confidential-sso https://www.dashlane.com/blog/streamline-logins-dashlane-con... uses remote attestation so that encryption keys can only be accessed by approved code - reducing risk from insider threats. I just wrote a blog post on another use case we are beginning to see: truly verifiable services. Say you want to operate a managed instance of an open-source project, to save users the operational hassle. How would a user know you're really running that OSS project, rather than a malicious version that steals their data? Using remote attestation, you can actually prove that: https://www.anjuna.io/blog/remote-attestation-enhancing-identity-with-confidential-computing https://www.anjuna.io/blog/remote-attestation-enhancing-iden...

nobody9999 3y ago
>The value of remote attestation in general (setting aside the implementation detail of RA-TLS) is that you have a form of software identity which is tied directly to the exact code that you're running. For example, if someone steals your service's API key, token, or cert, then they can impersonate your service. But if you are using remote attestation, they will not be able to generate the proper "credential" (a hardware-backed attestation document) to do it. That's an excellent point and I agree it's important to ensure strong authentication/authorization for such applications. However, as suggested in the Internet Draft, this would go far beyond simply ensuring that a specific peer is authorized to access another specific peer. Rather, it would essentially assign (based on keys, presumably in a secure enclave) a globally unique identifier that can then be tracked across the entire internet, rather than just ensuring that a particular set of peers are authorized to securely communicate. This is not a new issue and, for the most part, is a solved problem that absolutely does not require that arbitrary devices be permanently fingerprinted/identified. I'm sure that many folks may disagree, especially since "remote attestation" is the new shiny, but that doesn't mean there aren't perfectly functional methods already in use that provide similar functionality -- without the potential for spying/tracking.