Andrew Ayer, a security engineer and certificate transparency expert, writes about TLS certificates, CA incidents, and tools like git-crypt.
HN commenters praise his writeups on CA incidents and link git-crypt as a useful tool for encrypting secrets in Git repositories.
> UPDATE: Before people ask the potential question how the researchers are supposed to get their proper credit - my consideration is the following: Each of the researchers signs the paper with their own "public" key of a public-private key pair. This signature is uploaded as part of the paper upload. The "public" key is nevertheless kept secret by the researchers.
> When the legal risk is over and the researchers want to disclose their contribution, they simply make their "public" key really public. This way, anyboy can change that the signature that was uploaded from beginning on, indeed belong to this public key and thus to the respective researcher.
Commonly-used public key signature systems (RSA, ECDSA) do not provide the security properties necessary for this. Someone else who wants to claim credit for the research could cook up their own key pair that successfully validates the message and signature. This is called a duplicate signature key selection attack (https://www.agwa.name/blog/post/duplicate_signature_key_selection_attack_in_lets_encrypt)
"Systemd is far more than an init system: it is becoming a secondary operating system kernel, providing a log server, a device manager, a container manager, a login manager, a DHCP client, a DNS resolver, and an NTP client. These services are largely interdependent and provide non-standard interfaces for other applications to use. This makes any one component of systemd hard to replace, which will prevent more secure alternatives from gaining adoption in the future." [1]
"There will be better alternatives in the future that are more secure than what we have now. But adopting them will only be possible if systemd has not destroyed the modularity and standards-compliance that make innovation possible" [1]
[1] https://www.agwa.name/blog/post/how_to_crash_systemd_in_one_tweet
> Actually, this might not come as surprise to you...
Probably not, given he has a link to that same email as one of the very first things in his README.
> ...but there are a few reasons you should not do this
Having read the thread, it seems that everyone is talking about encrypting an entire repository in such a way, where as this project and (the surprisingly similar) git-crypt[1] are designed to encrypt only a few select files inside a repo--which isn't going to impact the git packer's compression techniques too much.
[1] http://www.agwa.name/projects/git-crypt/
These different representations also lead to frequent server side request forgery (SSRF) bypasses - someone might be blocking local IPv4 but you can still access their AWS metadata endpoint at ::ffff:169.254.169.254, etc.
For anyone using Ruby, I'm the author of a gem [1] that comprehensively protects against SSRF bugs. For anyone using Golang I recommend this [2] blog post.
[1]: https://github.com/arkadiyt/ssrf_filter
[2]: https://www.agwa.name/blog/post/preventing_server_side_request_forgery_in_golang
It’s not assuming MITM or that the attacker can upload the signature to the site.
The attack is that the attacker can reuse the already uploaded signature in a way that allows them to get certificates issued under their account instead of the initial owner.
This blog is a little confusing about that since it does read like they are supposed to upload their own sig with the graphic used.
This post and linked IETF report is a little more clear: https://www.agwa.name/blog/2015/12
This is one of the threats addressed by https://www.certificate-transparency.org/ .
If a CA issues a rogue cert and _does_ add it to the CT log, it's discoverable, at least in retrospect.
If a CA issues a rogue cert and _doesn't_ add it to the log, some browsers will refuse the connection when presented with that cert. https://www.agwa.name/blog/post/how_will_certificate_transparency_logs_be_audited_in_practice has more details about Chrome's implementation.