Re: embedding openssl source in sslcan

[Christian Seiler]

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

[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, and having tools like
sslscan readily available in Debian is greatly beneficial for security.


Cheers,
Thijs

Re: embedding openssl source in sslcan

[Hans-Christoph Steiner]

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

[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
>
>


-- 
Cheers,

Jonathan

Re: embedding openssl source in sslcan

[Moritz Mühlenhoff]

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

[Sebastian Andrzej Siewior]

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