179 karma · joined February 20, 2013
GCP Network has built in DoS mitigation as well (e.g. in the load balancing layer) so you get some protection from that for free.
https://cloud.google.com/iap/docs/using-tcp-forwarding#tunne...
For connecting VMs without public IPs to the outside world, Cloud NAT is the easiest answer. You could set one up yourself if you were so inclined (e.g. some forwarding rules and iptables rules on the bastion).
For ssh key distribution, there's a few options. You can store the key in Secret Manager and run your GCE VMs as a service account that has access to the key, then fetch it when pulling.
https://cloud.google.com/secret-manager/docs/
Something like:
$ ssh-add <(gcloud beta secrets versions access latest --secret=github-ssh-key)
On startup. I haven't actually tried out secret manager yet.
If you have too much time on your hands, you could rig something up with GCE vTPMs as well :)
https://cloud.google.com/blog/products/gcp/virtual-trusted-p...
* They know when they can serve 0RTT from their cache safely because they can be reasonably certain if handling a cached request is side effect free.
* If connections to backend origins are reasonably persistent, there's not much latency reduction benefit from 0RTT compared to connections from consumer user agents.
https://github.com/golang/go/blob/541f9c0345d4ec52d9f4be5913...
https://cs.nyu.edu/media/publications/TR2013-962.pdf
It’s pretty unweildy compared to HMAC construction because:
* each caveat addition requires local generation of a new asymmetric key pair
* the size of the macaroon grows linearly with the number of caveats. Each new caveat concatenates two asymmetric signatures to the append only signature. Each new caveat adds a public key to the macaroon ID.
* it requires a finalize step for security, meaning the final macaroon extender needs to know it’s the final extender.
It sounded rather impractical but I wouldn’t be surprised if improvements have been made since then.
* moving from using client certs to signing exported keying material[0] to prove key possession
* adding support for RSA keys
* adding support for multiple token bindings on a single connection (see referred token binding)
Fundamentally the two are very similar. I'm curious as to why you think origin bound certificates are more useful.
> In neither case do I anticipate widespread use
For the browser case:
* 0-RTT in TLS 1.3 (and resumption in general) negate a lot of the benefits of token binding. Big players aren't going to give this up (see QUIC).
* Hardware bound keys are interesting, but if crypto oracles are available on consumer machines, they are often far to slow to be used practically.
* Many compromises happen in the browser so token binding only marginally improves the security of cookies.
I think it will fall out of favor there. The service to service use case is an interesting one. If you turn off 0-RTT and session resumption, and bind tokens to hardware, the security properties start to look a lot like hardware bound mTLS. If the tooling ever gets developed, it might turn out to be a leaner alternative to a full blown PKI.
1. It works on all TLS connections, not just mTLS connections. It even works on unauthenticated TLS (although I wouldn't advise forgoing server authentication). That's the beauty of key binding the token. It's useless without the key.
2. It's unclear what the tokbind noun refers to in this paragraph. I'm going to assume that you are just referring to the token binding. A token binding lasts for the duration of a TLS connection (sans renegotiation and resumption which complicate things) and is derived from the [clientrandom,serverrandom,mastersecret] of the connection. The token binding secret is just an RSA or ECDSA keypair, independent of client or server certificates, that is generated when the token is issued. The token is bound to the keypair (e.g. by a hash of the public key that's stored in a JWT claim or stored in a database table keyed by an opaque oauth token).
3. Anyone can use token binding, not just members of the IETF TLS working group :)
From:
https://godoc.org/github.com/google/gvisor/pkg/sentry/platfo...
This statement is absolutely false. There is no upstream team separate from Google Cloud team. There is only the GKE team.