12:22 p.m.
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
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?
If you know how to build radsecproxy from source, please test the
'openssl11' branch [2] with OpenSSL 1.1.0 and let us know if it works
for you.
[2] git clone -b openssl11 https://git.nordu.net/radsecproxy.git
Thanks,
Linus
8:32 p.m.
Linus Nordberg <linus(a)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
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 :)
-Toke
8:47 p.m.
Toke Høiland-Jørgensen <toke(a)toke.dk> wrote
Mon, 05 Sep 2016 22:32:03 +0200:
Noted.
Thanks for maintaining a radsecproxy package!
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 :)
10:12 a.m.
Toke Høiland-Jørgensen <toke(a)toke.dk> wrote
Mon, 05 Sep 2016 22:32:03 +0200:
Linus Nordberg <linus(a)nordu.net> writes:
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
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>
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 :)
1:18 p.m.
Linus Nordberg <linus(a)nordu.net> writes:
Toke Høiland-Jørgensen <toke(a)toke.dk> wrote
Mon, 05 Sep 2016 22:32:03 +0200:
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/)?
Don't have a setup that'll let me test running right now... Will see if
I can get one setup...
-Toke
Linus Nordberg <linus(a)nordu.net> writes:
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 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>
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 :)
2:03 p.m.
Toke Høiland-Jørgensen <toke(a)toke.dk> wrote
Fri, 23 Sep 2016 15:18:10 +0200:
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!
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
4:56 p.m.
Linus Nordberg <linus(a)nordu.net> writes:
Toke Høiland-Jørgensen <toke(a)toke.dk> wrote
Fri, 23 Sep 2016 15:18:10 +0200:
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.
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 :)
-Toke
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
8:14 p.m.
Toke Høiland-Jørgensen <toke(a)toke.dk> wrote
Fri, 23 Sep 2016 18:56:48 +0200:
Linus Nordberg <linus(a)nordu.net> writes:
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". :))
Toke Høiland-Jørgensen <toke(a)toke.dk>
wrote
Fri, 23 Sep 2016 15:18:10 +0200:
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 :) >
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/)?> 
8:23 p.m.
23 Σεπ 2016, 23:14, ο/η Linus Nordberg <linus(a)nordu.net> έγραψε:
Toke Høiland-Jørgensen <toke(a)toke.dk> wrote
Fri, 23 Sep 2016 18:56:48 +0200:
Sure, on a number of TP-Link APs. Works like a charm for "mobile" eduroam. If it
wasn't for OpenSSL it would even fit on MR3020 (the ripe atlas v3 board).
:)
Linus Nordberg <linus(a)nordu.net> writes:
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? Toke Høiland-Jørgensen <toke(a)toke.dk>
wrote
Fri, 23 Sep 2016 15:18:10 +0200:
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 :) >> 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. (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". :))
_______________________________________________
radsecproxy mailing list
radsecproxy(a)lists.nordu.net
https://lists.nordu.net/listinfo/radsecproxy
8:27 p.m.
Linus Nordberg <linus(a)nordu.net> writes:
Toke Høiland-Jørgensen <toke(a)toke.dk> wrote
Fri, 23 Sep 2016 18:56:48 +0200:
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
Linus Nordberg <linus(a)nordu.net> writes:
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". :)) Toke Høiland-Jørgensen <toke(a)toke.dk>
wrote
Fri, 23 Sep 2016 15:18:10 +0200:
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 :) >> 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. 
6:47 a.m.
Hi Linus,
On 05/09/16 14:22, Linus Nordberg wrote:
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
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.
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
BR
Fabian
--
SWITCH
Fabian Mauchle, Network Engineer
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 30, direct +41 44 268 15 39
fabian.mauchle(a)switch.ch, www.switch.ch
7:33 a.m.
Fabian Mauchle <fabian.mauchle(a)switch.ch> wrote
Tue, 6 Sep 2016 08:47:19 +0200:
Yes.
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?
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. 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
10:49 a.m.
On 06/09/16 09:33, Linus Nordberg wrote:
Fabian Mauchle <fabian.mauchle(a)switch.ch> wrote
Tue, 6 Sep 2016 08:47:19 +0200:
Yes.
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?
At least it does
include all security fixes from 1.0.1t.
As for other bugfixes or features I don't know.
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. 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 Would it be possible to get 1.0.2 onto an RHEL 7.2
system and use that
instead?
I'll have to check with our systems department.
--
SWITCH
Fabian Mauchle, Network Engineer
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone +41 44 268 15 30, direct +41 44 268 15 39
fabian.mauchle(a)switch.ch, www.switch.ch
3036
days inactive
3054
days old
12 comments
4 participants
participants (4)
-
Fabian Mauchle -
Linus Nordberg -
Toke Høiland-Jørgensen -
Zenon Mousmoulas