Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Spoofing OpenPGP.js signature verification

codeanlabs.com

Post reply on HN
Print view View original

21–30 of 32 posts

Re: Spoofing OpenPGP.js signature verification

#21

Post by woodruffw »

jcranmer wrote: post #12
tptacek wrote: post #3

This is not normal. Modern cryptosystems don't have anything like PGP's insane "packet" format, which has caused other problems before this. There's no principal of design that would lead you to what PGP came up with, and the only reason we still have to deal with it is path dependence. I don't even care if you call the next design "PGP2", just throw this system in the bin and start over.

I'll admit that my knowledge of signed/encrypted email is mostly from S/MIME (and underlying CMS), so I'm curious if you could enlighten me on what PGP is doing that is so much more insane than that.

Well, I don't know if I would call PGP so much more insane than CMS or PKCS#7 :-). Definitely worse, but CMS is not high up on the list of honorable cryptographic envelope designs.

On the format level, CMS has some of the same flaws as PGP: dynamic TLV encodings (BER), extension points everywhere, and a disconnect between format and cryptographic versioning. On the cryptographic level, S/MIME benefits somewhat from certificates on the Internet PKI being less of a wild west than PGP certificates, and from having a community group (the S/MIME Cert WG of the CA/B Forum) invested in strengthening S/MIME's certificate profile beyond the baseline stipulated in RFC 5280. Of course, for non-public S/MIME deployments, none of that applies.

All that said, I don't think I would treat S/MIME (or CMS, or PKCS#7) as a guiding star: EFAIL affected S/MIME too[1]. But they have the "advantage" of being bad at just their niche (signing and encryption of email), versus being bad at every niche. The latter is PGP's historic curse.

[1]: https://efail.de/

Re: Spoofing OpenPGP.js signature verification

#22

Post by twiss »

woodruffw wrote: post #8
cbarrick wrote: post #7

Earlier quoted context omitted.

The issue discovered in TFA isn't about the format of individual packets (which "The PGP Problem" laments) but the grammar above the packets, i.e. the correct ordering of valid packets. Edit: foot successfully inserted in mouth

An absence of a canonical order or a definition of a well-formed packet sequence is itself a flaw in the packet format. Other cryptographic serialization and encoding schemes do not make this mistake.

FWIW, OpenPGP does have a definition of a well-formed packet sequence, e.g. for messages here: https://www.rfc-editor.org/rfc/rfc9580.html#name-openpgp-mes...

The packet sequence used by this vulnerability was not a valid OpenPGP message, as pointed out by the blog post (under the header "An invalid packet list").

Part of the issue in OpenPGP.js was that it didn't fully validate the message packet grammar, which has now been fixed: https://github.com/openpgpjs/openpgpjs/pull/1853

Re: Spoofing OpenPGP.js signature verification

#23

Post by tptacek »

twiss wrote: post #22
woodruffw wrote: post #8

Earlier quoted context omitted.

An absence of a canonical order or a definition of a well-formed packet sequence is itself a flaw in the packet format. Other cryptographic serialization and encoding schemes do not make this mistake.

FWIW, OpenPGP does have a definition of a well-formed packet sequence, e.g. for messages here: https://www.rfc-editor.org/rfc/rfc9580.html#name-openpgp-mes... The packet sequence used by this vulnerability was not a valid OpenPGP message, as pointed out by the blog post (under the header "An invalid packet list"). Part of the issue in OpenPGP.js was that it didn't fully validate the message packet grammar, which has…

When we evaluate the design of a cryptosystem, we debit implementation vulnerabilities (at least in mainstream implementations) to the design. It is part of the goal of a cryptosystem design to foreclose on the possibility of implementation vulnerabilities.

Re: Spoofing OpenPGP.js signature verification

#24

Post by twiss »

tptacek wrote: post #23
twiss wrote: post #22

Earlier quoted context omitted.

FWIW, OpenPGP does have a definition of a well-formed packet sequence, e.g. for messages here: https://www.rfc-editor.org/rfc/rfc9580.html#name-openpgp-mes... The packet sequence used by this vulnerability was not a valid OpenPGP message, as pointed out by the blog post (under the header "An invalid packet list"). Part of the issue in OpenPGP.js was that it didn't fully validate the message packet grammar, which has…

When we evaluate the design of a cryptosystem, we debit implementation vulnerabilities (at least in mainstream implementations) to the design. It is part of the goal of a cryptosystem design to foreclose on the possibility of implementation vulnerabilities.

I would usually tend to agree with that, I was mainly just responding to the specific claim that OpenPGP doesn't have a definition of a well-formed packet sequence, which is false.

Also, as a maintainer of OpenPGP.js, I'd say that while the complexity of OpenPGP certainly didn't help, quite a lot of things needed to go wrong to create this vulnerability:

- The message grammar validation was incomplete, as mentioned

- The streaming decryption/validation code affected how the packet sequence was processed

- A later optimization when not streaming affected it further in a way that caused an inconsistency in which packets were being read when

- Finally, the architecture of the code made it possible to return different data than what was verified, which should not have been possible (and we'll address this as well in a future refactor)

All in all, I would place more of the "blame" on OpenPGP.js rather than OpenPGP. That being said, I don't think placing blame is the most important here; both OpenPGP.js and OpenPGP should and will learn from this.

Re: Spoofing OpenPGP.js signature verification

#25

Post by deknos »

tptacek wrote: post #5
upofadown wrote: post #4

Earlier quoted context omitted.

To save typing, I came up with a commentary on "The PGP Problem": * https://articles.59.ca/doku.php?id=pgpfan:tpp The complaint about excessive complexity was about the packet length representation. That isn't a really great example. The PGP packet length representation is fairly straightforward.

You are writing this comment on a story where that packet format literally created a signature bypass vulnerability. Tell us more about how straightforward it is?

with that argument TLS would be insecure, because there are insecure TLS implementations.

Re: Spoofing OpenPGP.js signature verification

#26

Post by pvg »

deknos wrote: post #25
tptacek wrote: post #5

Earlier quoted context omitted.

You are writing this comment on a story where that packet format literally created a signature bypass vulnerability. Tell us more about how straightforward it is?

with that argument TLS would be insecure, because there are insecure TLS implementations.

That's not the argument, it's that it's a bad design repeatedly shown to be shown to be prone to serious vulnerabilities and it's silly to argue it's not a bad design at yet another such time.

People have made serious arguments for all sorts of design problems in SSL/TLS.

Re: Spoofing OpenPGP.js signature verification

#27

Post by jcranmer »

woodruffw wrote: post #21
jcranmer wrote: post #12

Earlier quoted context omitted.

I'll admit that my knowledge of signed/encrypted email is mostly from S/MIME (and underlying CMS), so I'm curious if you could enlighten me on what PGP is doing that is so much more insane than that.

Well, I don't know if I would call PGP so much more insane than CMS or PKCS#7 :-). Definitely worse, but CMS is not high up on the list of honorable cryptographic envelope designs. On the format level, CMS has some of the same flaws as PGP: dynamic TLV encodings (BER), extension points everywhere, and a disconnect between format and cryptographic versioning. On the cryptographic level, S/MIME benefits somewhat from c…

The way I've previously internalized it is CMS is bad principally because it's generic container of general generalizablity (on multiple levels, even) and the fundamentally wrong notion that signature and encryption are fully orthogonal. But generic generalizability can be ameliorated with a concerted, coordinated effort. As for S/MIME (specifically, working out how to embed CMS in MIME)... well, email and MIME make a good solution impossible from the outset, and S/MIME is probably the least bad you can do.

Encrypted email can never have a good solution simply because email is the poster child for "Why Postel's Law is a bad idea"

Re: Spoofing OpenPGP.js signature verification

#28

Post by woodruffw »

jcranmer wrote: post #27
woodruffw wrote: post #21

Earlier quoted context omitted.

Well, I don't know if I would call PGP so much more insane than CMS or PKCS#7 :-). Definitely worse, but CMS is not high up on the list of honorable cryptographic envelope designs. On the format level, CMS has some of the same flaws as PGP: dynamic TLV encodings (BER), extension points everywhere, and a disconnect between format and cryptographic versioning. On the cryptographic level, S/MIME benefits somewhat from c…

The way I've previously internalized it is CMS is bad principally because it's generic container of general generalizablity (on multiple levels, even) and the fundamentally wrong notion that signature and encryption are fully orthogonal. But generic generalizability can be ameliorated with a concerted, coordinated effort. As for S/MIME (specifically, working out how to embed CMS in MIME)... well, email and MIME make…

Completely agreed!

Re: Spoofing OpenPGP.js signature verification

#29

Post by tptacek »

twiss wrote: post #24
tptacek wrote: post #23

Earlier quoted context omitted.

When we evaluate the design of a cryptosystem, we debit implementation vulnerabilities (at least in mainstream implementations) to the design. It is part of the goal of a cryptosystem design to foreclose on the possibility of implementation vulnerabilities.

I would usually tend to agree with that, I was mainly just responding to the specific claim that OpenPGP doesn't have a definition of a well-formed packet sequence, which is false. Also, as a maintainer of OpenPGP.js, I'd say that while the complexity of OpenPGP certainly didn't help, quite a lot of things needed to go wrong to create this vulnerability: - The message grammar validation was incomplete, as mentioned -…

What you're seeing me and 'woodruffw implying is that modern formats are (deliberately) trivial to parse. OpenPGP is not. That is a security design feature that OpenPGP lacks, and it's a big one, because it's caused multiple issues already.

Re: Spoofing OpenPGP.js signature verification

#30

Post by twiss »

tptacek wrote: post #29
twiss wrote: post #24

Earlier quoted context omitted.

I would usually tend to agree with that, I was mainly just responding to the specific claim that OpenPGP doesn't have a definition of a well-formed packet sequence, which is false. Also, as a maintainer of OpenPGP.js, I'd say that while the complexity of OpenPGP certainly didn't help, quite a lot of things needed to go wrong to create this vulnerability: - The message grammar validation was incomplete, as mentioned -…

What you're seeing me and 'woodruffw implying is that modern formats are (deliberately) trivial to parse. OpenPGP is not. That is a security design feature that OpenPGP lacks, and it's a big one, because it's caused multiple issues already.

Yes, I understand and never said I disagree with that :) I'm just trying to provide some nuance and background about the specific issue discussed in this submission, as IMHO I think it's more interesting than making the same high-level points about OpenPGP over and over in every thread related to it (no offense meant, of course).
Post reply on HN