Re: embedding openssl source in sslcan
Hi, Am 2. Januar 2017 11:35:30 MEZ, schrieb Thijs Kinkhorst : >On Fri, December 23, 2016 18:53, Moritz Mühlenhoff wrote: >> Sebastian Andrzej Siewior schrieb: >> >> Please use t...@security.debian.org if you want to reach the security >> team, not debian-security@ldo. >> >>> tl;dr: Has anyone a problem if sslscan embeds openssl 1.0.2 in its >>> source? >> >> That's for post-stretch, right? Right now it can simply link against >> the 1.0.2 copy, >> >> Seems fine to me for that use case, and it won't need any security >> updates to the embedded openssl copy for all practical purposes >anyway. > >I agree, the risk for this use case is quite low, I don't think that's true: there are already attacks against forensic software out there, and if you have e.g. remote code execution in SSL client code, any usage of sslscan built against an unpatched openssl-insecure would be quite dangerous. There are other bugs you don't need to care about in this case: - timing side channels - most information leaks - insecure algorithms - DoS - weak RNG But just because the scanner use case isn't affected by these types of bugs doesn't mean you can skip security updates for this altogether. What is true is that the maintenance burden is somewhat lower. (OTOH one needs to be able to judge whether each specific vulnerability affects this or not, which also isn't entirely trivial ) >and having tools like >sslscan readily available in Debian is greatly beneficial for security. ACK on this front, I find sslscan very useful myself. Regards, Christian
Re: embedding openssl source in sslcan
On Fri, December 23, 2016 18:53, Moritz Mühlenhoff wrote: > Sebastian Andrzej Siewior schrieb: > > Please use t...@security.debian.org if you want to reach the security > team, not debian-security@ldo. > >> tl;dr: Has anyone a problem if sslscan embeds openssl 1.0.2 in its >> source? > > That's for post-stretch, right? Right now it can simply link against > the 1.0.2 copy, > > Seems fine to me for that use case, and it won't need any security > updates to the embedded openssl copy for all practical purposes anyway. I agree, the risk for this use case is quite low, and having tools like sslscan readily available in Debian is greatly beneficial for security. Cheers, Thijs
Re: embedding openssl source in sslcan
Seems like a decent idea for this, if other packages need an insecure openssl. As for making it hard to link to, the .so can be put into a non-standard dir so it has to be explicitly enabled both with a -lcrypto-insecure and -L/usr/lib/openssl-insecure. .hc Jonathan Yu: > Given that this would be useful for other tools, perhaps it's best to > create an "openssl-insecure" package which would ship a version of openssl > that has all the bells-and-whistles enabled (including the insecure ones). > We would have to take care that nothing is unintentionally linked to the > library. It would be a useful companion to software like testssl.sh (which > has similar requirements to sslscan) > > I certainly don't have strong feelings about this, especially given that I > haven't done any of the work... Just a thought :) > > On Fri, Dec 23, 2016 at 9:53 AM, Moritz Mühlenhoff wrote: > >> Sebastian Andrzej Siewior schrieb: >> >> Please use t...@security.debian.org if you want to reach the security >> team, not debian-security@ldo. >> >>> tl;dr: Has anyone a problem if sslscan embeds openssl 1.0.2 in its >>> source? >> >> That's for post-stretch, right? Right now it can simply link against >> the 1.0.2 copy, >> >> Seems fine to me for that use case, and it won't need any security >> updates to the embedded openssl copy for all practical purposes anyway. >> >> Cheers, >> Moritz >> >> > >
Re: embedding openssl source in sslcan
Given that this would be useful for other tools, perhaps it's best to create an "openssl-insecure" package which would ship a version of openssl that has all the bells-and-whistles enabled (including the insecure ones). We would have to take care that nothing is unintentionally linked to the library. It would be a useful companion to software like testssl.sh (which has similar requirements to sslscan) I certainly don't have strong feelings about this, especially given that I haven't done any of the work... Just a thought :) On Fri, Dec 23, 2016 at 9:53 AM, Moritz Mühlenhoff wrote: > Sebastian Andrzej Siewior schrieb: > > Please use t...@security.debian.org if you want to reach the security > team, not debian-security@ldo. > > > tl;dr: Has anyone a problem if sslscan embeds openssl 1.0.2 in its > > source? > > That's for post-stretch, right? Right now it can simply link against > the 1.0.2 copy, > > Seems fine to me for that use case, and it won't need any security > updates to the embedded openssl copy for all practical purposes anyway. > > Cheers, > Moritz > > -- Cheers, Jonathan
Re: embedding openssl source in sslcan
Sebastian Andrzej Siewior schrieb: Please use t...@security.debian.org if you want to reach the security team, not debian-security@ldo. > tl;dr: Has anyone a problem if sslscan embeds openssl 1.0.2 in its > source? That's for post-stretch, right? Right now it can simply link against the 1.0.2 copy, Seems fine to me for that use case, and it won't need any security updates to the embedded openssl copy for all practical purposes anyway. Cheers, Moritz
embedding openssl source in sslcan
tl;dr: Has anyone a problem if sslscan embeds openssl 1.0.2 in its source? sslscan [0] as packaged in Debian currently relies on external libssl as provided by the openssl package. The openssl package disables support compression, SSLv2 and SSLv3 which is good but it also means that sslscan can not detect a SSL implementation that is still providing support for one of these deprecated protocols or compression. One could say that it is not required to test for SSLv2 because if libssl does not support it then it is not possible for an application to offer it. However libssl is not the only SSL toolkit in Debian and one might need to scan a non-Debian / older machine. [0] https://github.com/rbsec/sslscan Sebastian