OpenSSL 1.1.1 is out and brings support for SHA-3 and TLS1.3. I think it might be possible to replace the main openssl package with this version and not have another -compat package around. The compat package should be dropped with releasing this.
The good news: OpenSSL 1.1.1 is compiling against everything else. Will need some time to run clean builds again (currently missing LFS file changes), but things look good.
Good news. Would you please open a branch with the changes and where we can work on integrating everything else like enabling TLS 1.3 for apache and so on? This should all be merged as a whole and not piece by piece.
(In reply to Michael Tremer from comment #2) > Good news. Would you please open a branch with the changes and where we can > work on integrating everything else like enabling TLS 1.3 for apache and so > on? This should all be merged as a whole and not piece by piece. I was about to ask you for this on git.ipfire.org so we do not need to merge this across infrastructures. :-) How can I set up a mirror of the ipfire-{2|3}.x tree on git.ipfire.org? Thanks.
I created those for you: https://git.ipfire.org/?p=people/pmueller/ipfire-2.x.git;a=summary https://git.ipfire.org/?p=people/pmueller/ipfire-3.x.git;a=summary
Thank you. I already pushed some commits, but are currently experiencing build errors... :-\
Hi Peter, just to inform you, have also build OpenSSL-1.1.1 already which build completely through the build process i used also the "weak_cipher" patch to integrate also the definition of the default set for TLSv1.3 ciphersuites (have seen you got that too) and am currently testing it in a VM with OpenVPN and while generating a new PKI i get an Can't load /var/ipfire/ovpn/ca/.rnd into RNG 140156678173120:error:2406F079:random number generator:RAND_load_file:Cannot open file:crypto/rand/randfile.c:88:Filename=/var/ipfire/ovpn/ca/.rnd it seems like Debian do have similar problems --> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=898470 but may you have already recognized and/or fixed it or may this is also not a problem on your system. Best, Erik
Hi, just find another one while IPSec PKI generation. OpenSSL hat einen Fehler verursacht: <br>139863134752960:error:02001002:system library:fopen:No such file or directory:crypto/bio/bss_file.c:74:fopen('/var/ipfire/certs/index.txt.attr' 'r')<br>139863134752960:error:2006D080:BIO routines:BIO_new_file:no such file:crypto/bio/bss_file.c:81: and it stops with this error message. Nevertheless, index.txt.attr are then created while the first try and the PKI can be generated with the second try, it stucks only with the first one. Just another info. Greetings, UE
(In reply to Erik Kapfer from comment #7) > Hi, > just find another one while IPSec PKI generation. > > OpenSSL hat einen Fehler verursacht: > <br>139863134752960:error:02001002:system library:fopen:No such file or > directory:crypto/bio/bss_file.c:74:fopen('/var/ipfire/certs/index.txt.attr' > 'r')<br>139863134752960:error:2006D080:BIO routines:BIO_new_file:no such > file:crypto/bio/bss_file.c:81: > > and it stops with this error message. Nevertheless, index.txt.attr are then > created while the first try and the PKI can be generated with the second > try, it stucks only with the first one. This is already tracked as #11904, but I did not look into solving this. Would anyone be up for grabbing that ticket and finding a solution?
Hi, haven´t found a good solution causing the .rnd problem. dd provides a possibility to generate them e.g.: # Add .rnd´d for r in / /var/ipfire/ovpn/ca/ /var/tmp/ /home/nobody/; do dd if=/dev/urandom of="${r}".rnd bs=1024 count=1; chmod 600 "${r}".rnd chown nobody:nobody "${r}.rnd" done but that´s possibly not that what is wanted here... all(In reply to Michael Tremer from comment #8) > (In reply to Erik Kapfer from comment #7) > > Hi, > > just find another one while IPSec PKI generation. > > > > OpenSSL hat einen Fehler verursacht: > > <br>139863134752960:error:02001002:system library:fopen:No such file or > > directory:crypto/bio/bss_file.c:74:fopen('/var/ipfire/certs/index.txt.attr' > > 'r')<br>139863134752960:error:2006D080:BIO routines:BIO_new_file:no such > > file:crypto/bio/bss_file.c:81: > > > > and it stops with this error message. Nevertheless, index.txt.attr are then > > created while the first try and the PKI can be generated with the second > > try, it stucks only with the first one. > > This is already tracked as #11904, but I did not look into solving this. > Would anyone be up for grabbing that ticket and finding a solution? OK, will you leave there then a message. Best, Erik
Do we want to have the static .rnd seeds at all? /dev/urandom should always be properly seeded now and OpenSSL can just use it.
Not really sure about that but the error message do not looks that good in my opinion and i haven´t found a switch to disable it... Have seen 1.1.1a is released --> https://www.openssl.org/news/changelog.html#x1 whereby a fix for RAND_add is addressed but not sure if this change this here, am currently build it and will go for a checkout then. Have encountered another problem where i´am currently not 100% sure where it comes from. I tried Peter´s default cipher lists patch --> https://git.ipfire.org/?p=people/pmueller/ipfire-2.x.git;a=blob;f=src/patches/openssl-1.1.1-default-cipherlist.patch;h=7f1e4100bdcd971da7ef811ad36661b86402a56a;hb=70d48c264c1fb1987b52d190fecf870d00ceb148 out and while installation it was not possible to set the root password accordingly but have also updated shadow so may it comes from this side. Another thing causing the cipher list. SEED, MD5 and 3DES are disabled as far as i can see, we could get into trouble with this i think. Best, Erik
(In reply to Erik Kapfer from comment #11) > Another thing causing the cipher list. SEED, MD5 and 3DES are disabled as > far as i can see, we could get into trouble with this i think. Could you please open a new ticket that blocks this one? We should make sure that we remove those before we merge OpenSSL 1.1.1 or consider enabling those algorithms again.
(In reply to Erik Kapfer from comment #11) > Have encountered another problem where i´am currently not 100% sure where it > comes from. I tried Peter´s default cipher lists patch --> > https://git.ipfire.org/?p=people/pmueller/ipfire-2.x.git;a=blob;f=src/ > patches/openssl-1.1.1-default-cipherlist.patch; > h=7f1e4100bdcd971da7ef811ad36661b86402a56a; > hb=70d48c264c1fb1987b52d190fecf870d00ceb148 out and while installation it > was not possible to set the root password accordingly but have also updated > shadow so may it comes from this side. Have double checked this one and it seems that the updated shadow causes this problem so please ignore this. Best, Erik
Hello Erik, thank you for working on this. Glad the cipher patch worked. :-) At the moment, I get the feeling you are more deeply into this topic than I am. Would it suit you to bring this into IPFire 2.x ? Thanks, and best regards, Peter Müller
Hello Peter, (In reply to Peter Müller from comment #14) > Hello Erik, > > thank you for working on this. Glad the cipher patch worked. :-) > You are welcome, thank you too for your work, looking forward to see more of this ;-) . > At the moment, I get the feeling you are more deeply into > this topic than I am. Would it suit you to bring this into > IPFire 2.x ? > It is possibly not a good idea to work only with two_eyes/one_mind/one_time_budget on that topic. If you take a look into the Debian bug reports log --> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=907015 (IPFire do provides also some packages listed in there) OpenSSL-1.1.1 is possible more work than expected. May it is because Debian uses now SECLEVEL2 --> https://wiki.debian.org/ContinuousIntegration/TriagingTips/openssl-1.1.1 which we can also thinking about ? In general it might also be an idea to take also a look to the openssl.conf files on the system for possible extensions. A good thing is that it builds through (easier then with the update to 1.1.0) so we can go for some intenser tests. Will try to install the new OpenSSL on one of my production machines via backup restore to get a better live and direct response for this update. Best, Erik
Update from today's telco: Erik is merging patches from Peter and himself together and is submitting this to the mailing list to be merged for c128.
Thank you!
Hi all, did a double check with https://bugzilla.ipfire.org/show_bug.cgi?id=11943 and i currently stuck again with an, as i thought, already fixed problem while first X509 generation but also if an already running IPsec generates a new client, the following appears Using configuration from /etc/ssl/openssl.cnf Can't load /home/nobody/.rnd into RNG 139848421155328:error:2406F079:random number generator:RAND_load_file:Cannot open file:crypto/rand/randfile.c:98:Filename=/home/nobody/.rnd with the first run of the new RAND dir, nevertheless OpenSSL produces /home/nobody/.rnd but stucks while first try, the second try works then as expected but this is not a good solution in my opinion. What are you guys thinking about to execute an openssl ca -config /etc/ssl/openssl.cnf > /dev/null 2>&1 via update.sh ? Since 'req' and 'ca' uses the openssl config where the new RAND directory has been set, in my tests /home/nobody/.rnd will then be created and this problem doesn´t appear for IPSec. But fresh installation doesn´t use update.sh´s so there is again something to thinking about... Currently not sure why this happens again but am happy that i find it with the double check. Best, Erik
Have you tried removing that line so it won’t use this file? We don’t need it. OpenSSL should use the kernel’s RNG.
Best solution! Tested it with OpenVPN and IPSec and it worked this way. What should we do then with the already existing .rnd´s under /var/tmp and /var/ipfire/ovpn/ca ? Best, Erik
Delete them in the updater
Erik takes care of this (thank you), and it is on MODIFIED by now...
https://blog.ipfire.org/post/ipfire-2-21-core-update-128-released