On Mon, 3 Aug 2015 at 20:27 Thomas Voegtlin <thom...@electrum.org> wrote:
> On 08/03/2015 10:41 AM, Tristan Seligmann wrote:
> > In addition,
> > quite a bit of the certificate handling code does things incorrectly
> > (see eg. the certificate chain verification code[1] that does not
> > check the certificate purpose, allowing anyone with a valid cert to
> > sign a fraudulent cert as if they were a CA).
> >
>
> Instead of suggesting that there are "quite a bit" of incorrect things,
> and then citing one example, can you provide the full list of problems
> that you see?
>
Sorry, I believe I owe you an apology for my carelessly written email.
Firstly, I took a look at the code again, and I think the single issue I
described does not actually exist, I probably misread the code before. (To
be precise, while the code does not check the key usage, it *does* check
the "Basic Constraints" extension which I believe is the correct check to
prevent the flaw I mistakenly identified).
While it is quite possible for newly written certificate-handling / X509
code to be buggy simply due to the complex nature of what this entails, I
don't have any specific issues to highlight at this time, and I can hardly
claim to be an expert in this area myself, so I retract my previous claim.
However, the primary issue is still dealing with tlslite somehow: I do not
think the FTP masters / security team will be happy with me distributing an
embedded copy of tlslite in the electrum package, and I don't feel
comfortable maintaining tlslite in Debian either way given the
circumstances.
Note that python-cryptography is the "cryptography" library upon which
python-openssl ("PyOpenSSL") is based, not "pycrypto" which is a different
library; but cryptography does use cffi to bind to OpenSSL etc., so is also
not pure python. Unfortunately most of the existing mature TLS / X.509 /
etc. handling code exists in C libraries...
