Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.security > #5156 > unrolled thread

embedding openssl source in sslcan

Back to article view | Back to linux.debian.security

Contents

  embedding openssl source in sslcan Sebastian Andrzej Siewior <sebastian@breakpoint.cc> - 2016-12-22 13:40 +0100
    Re: embedding openssl source in sslcan Moritz Mühlenhoff <jmm@inutil.org> - 2016-12-24 19:10 +0100
      Re: embedding openssl source in sslcan Jonathan Yu <jawnsy@cpan.org> - 2016-12-24 22:20 +0100
        Re: embedding openssl source in sslcan Hans-Christoph Steiner <hans@at.or.at> - 2016-12-26 11:50 +0100
      Re: embedding openssl source in sslcan "Thijs Kinkhorst" <thijs@debian.org> - 2017-01-02 11:40 +0100
        Re: embedding openssl source in sslcan Christian Seiler <christian@iwakd.de> - 2017-01-02 17:20 +0100

#5156 — 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

[toc] | [next] | [standalone]

#5158

Sebastian Andrzej Siewior <sebastian@breakpoint.cc> schrieb:

Please use team@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

[toc] | [prev] | [next] | [standalone]

#5159

[Multipart message — attachments visible in raw view] — view raw

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 <jmm@inutil.org> wrote:

> Sebastian Andrzej Siewior <sebastian@breakpoint.cc> schrieb:
>
> Please use team@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

[toc] | [prev] | [next] | [standalone]

#5160

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 <jmm@inutil.org> wrote:
> 
>> Sebastian Andrzej Siewior <sebastian@breakpoint.cc> schrieb:
>>
>> Please use team@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
>>
>>
> 
> 

[toc] | [prev] | [next] | [standalone]

#5161

On Fri, December 23, 2016 18:53, Moritz Mühlenhoff wrote:
> Sebastian Andrzej Siewior <sebastian@breakpoint.cc> schrieb:
>
> Please use team@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

[toc] | [prev] | [next] | [standalone]

#5162

Hi,

Am 2. Januar 2017 11:35:30 MEZ, schrieb Thijs Kinkhorst <thijs@debian.org>:
>On Fri, December 23, 2016 18:53, Moritz Mühlenhoff wrote:
>> Sebastian Andrzej Siewior <sebastian@breakpoint.cc> schrieb:
>>
>> Please use team@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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.security

csiph-web