Toke Høiland-Jørgensen toke@toke.dk wrote Mon, 05 Sep 2016 22:32:03 +0200:

Linus Nordberg linus@nordu.net writes:

...

Hi,

Thanks to Faidon, we've got an issue [1] tracking the work of getting radsecproxy to work with OpenSSL 1.1.

[1] https://project.nordu.net/browse/RADSECPROXY-66%3E The questions now are 1) does the proposed patch work for you and 2) how little backwards compatibility can we get away with?

If you're a radsecproxy user, what version(s) of OpenSSL do you really need support for?

I'm maintaining a radsecproxy package for OpenWRT/LEDE which runs openssl 1.0.2h. Keeping compatibility with that would be nice :)

The least painful way of supporting 1.0.2 that I've found is to stop using libcrypto (from OpenSSL) for MD5 and HMAC(MD5).

The openssl11 branch [1] now uses libnettle instead. Please give it a try with 1.0.2 and let me know if things still work well for you. Don't forget to try to authenticate some users and please test both succesful and failing authentication attempts. There's a chance for actual breakage here.

[1] https://git.nordu.net/?p=radsecproxy.git;a=shortlog;h=refs/heads/openssl11

Thanks, Linus

Toke Høiland-Jørgensen toke@toke.dk wrote Fri, 23 Sep 2016 15:18:10 +0200:

...

...

I'm maintaining a radsecproxy package for OpenWRT/LEDE which runs openssl 1.0.2h. Keeping compatibility with that would be nice :)

The least painful way of supporting 1.0.2 that I've found is to stop using libcrypto (from OpenSSL) for MD5 and HMAC(MD5).

The openssl11 branch [1] now uses libnettle instead. Please give it a try with 1.0.2 and let me know if things still work well for you. Don't forget to try to authenticate some users and please test both succesful and failing authentication attempts. There's a chance for actual breakage here.

[1] https://git.nordu.net/?p=radsecproxy.git;a=shortlog;h=refs/heads/openssl11

Well, it compiles on openwrt at least (or rather, the master branch does). However, pulling in two crypto libraries on an embedded platform is not ideal. Would it be feasible to drop openssl entirely in favour of libnettle? Or maybe something like mbedtls (formerly polarssl; https://tls.mbed.org/)?

What are the issues with two libraries? Size? Assuming you're linking statically I wouldn't expect the few libnettle functions to be too expensive. But I haven't checked closely.

Nettle does crypto stuff but no TLS so something like mbedtls or any of the other TLS libraries would indeed be needed. Depending on their API, they might be more or less complicated to use as a drop in replacement for OpenSSL. Please let me know if you get something working (but I have to admit that I'm not overly eager on supporting another TLS library.) And oh, beware of the multithreaded nature of this program!

Toke Høiland-Jørgensen toke@toke.dk wrote Fri, 23 Sep 2016 18:56:48 +0200:

Linus Nordberg linus@nordu.net writes:

...

Toke Høiland-Jørgensen toke@toke.dk wrote Fri, 23 Sep 2016 15:18:10 +0200:

...

...

...

I'm maintaining a radsecproxy package for OpenWRT/LEDE which runs openssl 1.0.2h. Keeping compatibility with that would be nice :)

The least painful way of supporting 1.0.2 that I've found is to stop using libcrypto (from OpenSSL) for MD5 and HMAC(MD5).

The openssl11 branch [1] now uses libnettle instead. Please give it a try with 1.0.2 and let me know if things still work well for you. Don't forget to try to authenticate some users and please test both succesful and failing authentication attempts. There's a chance for actual breakage here.

[1] https://git.nordu.net/?p=radsecproxy.git;a=shortlog;h=refs/heads/openssl11%3...

Well, it compiles on openwrt at least (or rather, the master branch does). However, pulling in two crypto libraries on an embedded platform is not ideal. Would it be feasible to drop openssl entirely in favour of libnettle? Or maybe something like mbedtls (formerly polarssl; https://tls.mbed.org/)?%3E

What are the issues with two libraries? Size? Assuming you're linking statically I wouldn't expect the few libnettle functions to be too expensive. But I haven't checked closely.

Static linking? Blasphemy! ;) But no, I don't have hard numbers on the size differences either way. And this is not something that's bothering me enough to write code. Just thought I'd point it out as a consideration for when you're doing house-cleaning and/or planning future development directions :)

It's a good point and one that I didn't consider when adding libnettle as an unconditional dependency. Actually, I'm not thinking of radsecproxy as something living on anything smaller than a "server" in a "data center". Anyone else running radseproxy under more constrained environment?

(Last time I looked at embedded, shared libraries were out of the question. Since then, I guess there are more flavours to consider than "embedded" and "not embedded". :))

Linus Nordberg linus@nordu.net writes:

Toke Høiland-Jørgensen toke@toke.dk wrote Fri, 23 Sep 2016 18:56:48 +0200:

...

Linus Nordberg linus@nordu.net writes:

...

Toke Høiland-Jørgensen toke@toke.dk wrote Fri, 23 Sep 2016 15:18:10 +0200:

...

...

...

I'm maintaining a radsecproxy package for OpenWRT/LEDE which runs openssl 1.0.2h. Keeping compatibility with that would be nice :)

The least painful way of supporting 1.0.2 that I've found is to stop using libcrypto (from OpenSSL) for MD5 and HMAC(MD5).

The openssl11 branch [1] now uses libnettle instead. Please give it a try with 1.0.2 and let me know if things still work well for you. Don't forget to try to authenticate some users and please test both succesful and failing authentication attempts. There's a chance for actual breakage here.

[1] https://git.nordu.net/?p=radsecproxy.git;a=shortlog;h=refs/heads/openssl11%3...

Well, it compiles on openwrt at least (or rather, the master branch does). However, pulling in two crypto libraries on an embedded platform is not ideal. Would it be feasible to drop openssl entirely in favour of libnettle? Or maybe something like mbedtls (formerly polarssl; https://tls.mbed.org/)?%3E

What are the issues with two libraries? Size? Assuming you're linking statically I wouldn't expect the few libnettle functions to be too expensive. But I haven't checked closely.

Static linking? Blasphemy! ;) But no, I don't have hard numbers on the size differences either way. And this is not something that's bothering me enough to write code. Just thought I'd point it out as a consideration for when you're doing house-cleaning and/or planning future development directions :)

It's a good point and one that I didn't consider when adding libnettle as an unconditional dependency. Actually, I'm not thinking of radsecproxy as something living on anything smaller than a "server" in a "data center". Anyone else running radseproxy under more constrained environment?

(Last time I looked at embedded, shared libraries were out of the question. Since then, I guess there are more flavours to consider than "embedded" and "not embedded". :))

Well, the LEDE/OpenWrt people are doing a great job of building a modern Linux distro (including dynamic linking :)) that fits in a couple of megabytes of flash. One of the ways of achieving that is asking for basically every change: What is the image size impact?

And the nice thing about using radsecproxy on such a device is that it means you can offload all the user authentication to one of those "server" thingies. I'm not sure how many people actually use the radsecproxy package, but someone contributed scripts to generate configuration from the platform-specific configuration language. So I guess someone is finding it useful :)

-Toke

Fabian Mauchle fabian.mauchle@switch.ch wrote Tue, 6 Sep 2016 08:47:19 +0200:

...

The questions now are 1) does the proposed patch work for you

At least id does NOT compile without OpenSSL 1.1 - which is probably to be expected.

Yes.

...

2. how little backwards compatibility can we get away with?

If you're a radsecproxy user, what version(s) of OpenSSL do you really need support for?

Currently running on RHEL 7.2, OpenSSL 1.0.1e

That seems terribly old -- the 1.0.1 series is at 1.0.1t. Any chance it has a bunch of backports and actually is more close to 1.0.1t?

Would it be possible to get 1.0.2 onto an RHEL 7.2 system and use that instead?