public inbox for development@lists.ipfire.org
 help / color / mirror / Atom feed
From: ummeegge <ummeegge@ipfire.org>
To: development@lists.ipfire.org
Subject: Re: Upgrading to OpenSSL 1.1.0
Date: Fri, 12 Jan 2018 12:02:15 +0100	[thread overview]
Message-ID: <E8AD7127-8BAB-4891-8790-6D895EF0162C@ipfire.org> (raw)
In-Reply-To: <1515604119.2392.12.camel@ipfire.org>

[-- Attachment #1: Type: text/plain, Size: 5073 bytes --]

Hi Michael,

> Erik: I am not sure why those packages won't build for you. I patched a
> number of them in my branch:
> 
>  https://git.ipfire.org/?p=people/ms/ipfire-2.x.git;a=shortlog;h=refs/
> heads/openssl-11

Have loaded the current Core 118

I fetched your changes via:

git remote add openssl-11 ssh://ummeegge(a)git.ipfire.org/pub/git/people/ms/ipfire-2.x.git
git fetch openssl-11
git checkout openssl-11

and have build it with the same issues then mentioned before. 

> 
> I will rebase this branch now on where next currently is and build it
> again.

Haven´t found it, can you point out how to get it ?

> I only expect asterisk to crash then which we need to update. It
> seems that Dirk has retired as maintainer for asterisk. I can try
> switching Asterisk to gnutls instead, but generally I would like to
> keep as much as we can on OpenSSL since that is our primary library.

I think an update of Asterisk and his components should work also with the new OpenSSL. 
At least in my environment Asterisk has build with OpenSSL-1.1.0g, but there was one more dependency (jansson) needed. Changes can be found in here --> https://git.ipfire.org/?p=people/ummeegge/ipfire-2.x.git;a=commit;h=2d940ba2187a53cf52d2191a36c3897636b9600c .

> 
> So, again for me: What is the status of OpenVPN 2.4 now? I guess that
> should build with OpenSSL 1.1 out of the box.

OpenVPN-2.4.4 has build with OpenSSL-1.1.0g have included also the LZ4 compression lib but otherwise it builds out of the box but OpenVPN won´t start without some changes in ovpnmain.cgi. In here --> https://github.com/ummeegge/OpenVPN_30.08.2017/commit/7460cead169ea919f66ad7068e764fef37bf8f8b#diff-2011d5d928fd214cacb83844729c65cc a little more then needed has been done but it describes very closely the needed changes.
The most important are:
1) The script-security flag 'system' can not be used anymore the server won´t start if this isn´t fixed.
2) OpenVPN have added an automatic cipher negotiation with 2.4.x which should be manageable in my opinion. If someone needs to have other ciphers then the strongest defaults e.g. for the usage of HWRNG this option should be switchable with an OFF/ON checkbox. 
This option is also pushable so it can be used individually per client so it can be managed via the global section but also over the CCD section for each client.

> 
> Would you be able to submit patches so that it builds already? Any
> changes to the CGI files to add new ciphers can and should be a second
> patch.

I can do this but it might be great if i can make before some tests with the new OpenSSL lib. Would it be OK for you if i push the first part as in the Github example ? Have already changed the language file description and left Camellia  out the --ncp-ciphers list (which is equal to OpenVPN manpage). 

> 
> I am not sure if we should expect any problems with changed
> configuration parameter where we need to migrate configuration files.
> We are already using the new parameters where possible. So is there any
> other work left to do?

The main work is described above, OpenVPN-2.4.x checks the version of the clients, if they are <= 2.4 OpenVPN uses the already presant --cipher ALG, if the client are >= 2.4 it will negotiate the best cipher which is normally AES-256-GCM which is also a complete new algorithm for OpenVPN (no cipher block chaining).

>> 
>> also causing the "Sweet32 Birthday attacks" --> https://sweet32.info/ a lot of ciphers which are used in IPFires OpenVPN are marked as deprecated and should. in my opinion, marked in the WUI as such. A potential new digest "BLAKE2b" has also been introduced which i´am not sure if it works properly and if it works, if it should be integrated into the menu of IPFires OpenVPN WUI.
> 
> Not sure if we should support something experimental. Might become a
> headache later…

Yes i think so too. Nevertheless i think we should introduce at least the new Galois/Counter Mode (available with 128, 196 and 256 bit) which is somehow the default of the new OpenVPN if possible. Would do this with a second patch where it might also be  an idea to list all the deprecated ciphers as such (via optgroup label) ?

> 
>> My main problem currently is that i can not test all that cause the installation process interrupts "Unable to install the language cache" , message comes from here --> https://github.com/ipfire/ipfire-2.x/blob/cf361ef4b55134254150b5070069f9d25b201bd1/src/installer/po/de.po#L272 i think.
>> Some help in there might be great to proceed further with the OpenVPN update.
> 
> Are you still stuck at this?

Yes as above mentioned have loaded Core118 and fetched your branch but stuck with the exact same problems as described in here --> https://lists.ipfire.org/pipermail/development/2017-December/003831.html . If i get something wrong here it might be great if you can point me to the right direction.


By the way, i wish you all a happy new year and all the best for 2018 :-) .

Greetings,

Erik


> 


  reply	other threads:[~2018-01-12 11:02 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-29 13:12 Michael Tremer
2017-12-03  7:34 ` ummeegge
2017-12-07 11:21   ` ummeegge
2018-01-10 17:08     ` Michael Tremer
2018-01-12 11:02       ` ummeegge [this message]
2018-01-13 12:17         ` Michael Tremer
2018-01-14 10:59           ` ummeegge
2018-01-15 11:58             ` Michael Tremer
2018-01-16 11:36               ` ummeegge
2018-01-16 12:34                 ` Jeffrey Walton
2018-01-16 13:02                   ` Michael Tremer
2018-01-16 12:56                 ` Michael Tremer
2018-01-16 14:28                   ` Horace Michael
2018-01-18 10:07                   ` ummeegge
2018-01-13 12:30       ` Jeffrey Walton
2018-01-15 11:59         ` Michael Tremer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=E8AD7127-8BAB-4891-8790-6D895EF0162C@ipfire.org \
    --to=ummeegge@ipfire.org \
    --cc=development@lists.ipfire.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox