3 ms·

Cert pinning is not a solution and defeats legitimate traffic inspection cases. It also just moves the goalposts as the author discusses it can be defeated by a

by dcow 2y ago

Cert pinning is not a solution and defeats legitimate traffic inspection cases. It also just moves the goalposts as the author discusses it can be defeated by a modified app binary. The industry has moved on. Sign your data if modification in-flight is a threat. I’m surprised google isn't doing that.

dambi0 2y ago
Alternatively perhaps the cost of implementing / performing the overhead of signing and verification isn’t worth the cost given the relatively few people who are likely to do this
JoshTriplett 2y ago
> Sign your data if modification in-flight is a threat. Which effectively pins a different key in the binary. Might as well use certificate pinning, which provides both signing and encryption without a second layer of crypto.
- dcow 2y ago
  Only naively. You can do a key exchange.
gowld 2y ago
A legitimiate traffic inspection case, from the content publisher's perspective, would have an alternate certificate backed by a trusted authority who agreed to protect the ads.
thaumasiotes 2y ago
> It also just moves the goalposts as the author discusses it can be defeated by a modified app binary. The industry has moved on. Sign your data if modification in-flight is a threat. As a sibling comment has also pointed out, signing the data won't help against a user who's modifying the client. You can change the signature the client is expecting on your certificate... and you can also change the signature the client is expecting on your data.
- dcow 2y ago
  It protects against things other than the intended client modifying the data. Someone said we need cert pinning to protect data integrity in the face of MITM. I am saying signing your requests solves MITM modifying the traffic, so you don’t need cert pinning. Solving binary integrity in hostile compute environments is a different problem.
fastball 2y ago
Cert pinning is a solution. Just because it is not an ideal solution and it is anti-consumer does not make it "not a solution". You can't modify an app binary on an Apple TV without first jailbreaking. So cert pinning in this case would go from "anyone with a pihole or equivalent can block YT ads on their Apple TV" to "people who jailbreak their Apple TV and install a cert pinning breaker and have a pihole type setup can block ads". If you are google and your goal is to get people to watch ads, cert pinning is clearly a win if you are at all worried about things like the OP. Clearly they are not very worried, presumably because the bar set by the OP is already too technical for most people (even if it was packaged in a more consumable way).
jeroenhd 2y ago
When you're running a proprietary video service that's supported by ads and analytics, there aren't that many "legitimate traffic inspection cases". Google prefers people not to mess with their network traffic and would also prefer it to be a bit harder to write YouTube downloader scripts. From a user perspective, you'd want to break all TLS connections and sniff every bit of data on your network, but that's not the perspective Google has when developing their code. Signing data is just duplicating TLS security measures with a second key. TLS already signs the data, Google just needs to verify the root of trust.

by dcow 2y ago

dambi0 2y ago

Alternatively perhaps the cost of implementing / performing the overhead of signing and verification isn’t worth the cost given the relatively few people who are likely to do this

JoshTriplett 2y ago

> Sign your data if modification in-flight is a threat. Which effectively pins a different key in the binary. Might as well use certificate pinning, which provides both signing and encryption without a second layer of crypto.

dcow 2y ago
Only naively. You can do a key exchange.

gowld 2y ago

A legitimiate traffic inspection case, from the content publisher's perspective, would have an alternate certificate backed by a trusted authority who agreed to protect the ads.

thaumasiotes 2y ago

> It also just moves the goalposts as the author discusses it can be defeated by a modified app binary. The industry has moved on. Sign your data if modification in-flight is a threat. As a sibling comment has also pointed out, signing the data won't help against a user who's modifying the client. You can change the signature the client is expecting on your certificate... and you can also change the signature the client is expecting on your data.

dcow 2y ago
It protects against things other than the intended client modifying the data. Someone said we need cert pinning to protect data integrity in the face of MITM. I am saying signing your requests solves MITM modifying the traffic, so you don’t need cert pinning. Solving binary integrity in hostile compute environments is a different problem.

fastball 2y ago

Cert pinning is a solution. Just because it is not an ideal solution and it is anti-consumer does not make it "not a solution". You can't modify an app binary on an Apple TV without first jailbreaking. So cert pinning in this case would go from "anyone with a pihole or equivalent can block YT ads on their Apple TV" to "people who jailbreak their Apple TV and install a cert pinning breaker and have a pihole type setup can block ads". If you are google and your goal is to get people to watch ads, cert pinning is clearly a win if you are at all worried about things like the OP. Clearly they are not very worried, presumably because the bar set by the OP is already too technical for most people (even if it was packaged in a more consumable way).

jeroenhd 2y ago

When you're running a proprietary video service that's supported by ads and analytics, there aren't that many "legitimate traffic inspection cases". Google prefers people not to mess with their network traffic and would also prefer it to be a bit harder to write YouTube downloader scripts. From a user perspective, you'd want to break all TLS connections and sniff every bit of data on your network, but that's not the perspective Google has when developing their code. Signing data is just duplicating TLS security measures with a second key. TLS already signs the data, Google just needs to verify the root of trust.