[DorothySim]

They also take into account the state of the machine you're working on. So locked bootloader and probably a client cert in TPM-like component, plus "device health". Client certs alone are good for authentication (don't work in HTTP/2 though) but they want to reach even better target - no malicious software running on your computer.

That's from reading old papers, I don't know if anything changed now.

[maxsaltonstall]

That's correct. Previous papers touch on the inventory data pipeline and machine health, though without as much detail as I might like in your shoes. Our agents track a wide variety of things on client machines, and we use that inventory data to determine how trustworthy a machine could be. [I work at Google, and helped make these papers, and blog post, happen]

[mattweinberg]

Also FYI- there's visible template code here: https://cloud.google.com/iap/docs/quickstart

[DorothySim]

Interesting design. As far as I understood from old papers client certificates are used only to identify the device while user authentication is handled differently.

Could you elaborate on the technical details on user authentication? (If that's not top-super-secret) I guess it's just like accounts.google.com for Enterprise with mandatory 2FA (username+password+U2F key?). Does it work the same on mobile/Android (U2F via NFC or codes)?

[weeks]

Android supports U2F via NFC and Bluetooth now, which is used for user authentication on Android devices. We've also released an (experimental?) iOS app to support U2F over Bluetooth.

https://itunes.apple.com/us/app/google-smart-lock/id11520663...

[e12e]

How is trust anchored?

There's tpm and secure boot - does the (presumably signed, in the trusted boot->os->user binary/service-path) agent access signing services from tpm - backed by a key in tpm, and use that to identify itself as an authentic agent?

Otherwise I can't see how an (admin) user couldn't extract the key from ram and run the os and agent in a vm?

[noinsight]

> Client certs alone are good for authentication (don't work in HTTP/2 though)

Um, what? Did client certs get removed from HTTP 2?

[j_s]

I have been collecting conflicting reports on HTTP/2 client certificate support:

14 months ago: "No. But TLS!" https://news.ycombinator.com/item?id=11556762

7 months ago: "421" https://news.ycombinator.com/item?id=13022596

Maybe it would be worth the time to test out the various implementations if someone has not already done so?

--

Doing some preliminary research, support is still a working draft https://datatracker.ietf.org/doc/draft-bishop-httpbis-http2-... source: https://daniel.haxx.se/blog/2016/08/18/http2-connection-coal...

[detaro]

Yes. As far as I understand, the problem was that the requirement for a certificate is a per-request thing, but HTTP 2 can have multiple requests in flight over the same TLS connection at the same time and thus can't just renegotiate the connection when it comes up. There have been proposals to fix this, but nothing has gained the necessary interest and traction.

Servers can ask the client to fall back to HTTP 1.1 instead, and then use client-certificates there.

[madjam002]

Ah that's a good point, thanks!