Opened at 2012-04-19T19:37:08Z
Last modified at 2020-01-17T14:08:17Z
#1722 closed defect
respond to OpenSSL ASN.1 parsing bug — at Version 2
| Reported by: | davidsarah | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | undecided |
| Component: | packaging | Version: | 1.9.1 |
| Keywords: | openssl security packaging | Cc: | |
| Launchpad Bug: |
Description (last modified by davidsarah)
http://lists.grok.org.uk/pipermail/full-disclosure/2012-April/086585.html
- review source of pyOpenSSL to see what calls it makes to OpenSSL, check assertion that SSL/TLS is not affected.
- what is the impact on Tahoe, if any?
- if needed write advisory, put on website and post to tahoe-dev
- understand how pyOpenSSL links to OpenSSL, and whether we should change pyOpenSSL and bump Tahoe's dependency on it.
Change History (2)
comment:1 Changed at 2012-04-19T19:40:08Z by warner
comment:2 Changed at 2012-04-19T19:41:30Z by davidsarah
- Description modified (diff)
Note: See
TracTickets for help on using
tickets.
http://www.openssl.org/news/secadv_20120419.txt claims that the bug doesn't affect the SSL/TLS code (because that code uses the in-memory ASN1 parsers, rather than the BIO/FILE parsers). The only time Foolscap passes *in* a certificate is when setting up a Tub (i.e. reading back the .pem file that was written out by an earlier invocation), in which case the data was generated locally.
So my first hunch is that we're ok. If the openssl problem turns out to be vulnerable to receipt of corrupt certificates over the wire (as opposed to from local disk), then we'd be in trouble.