Opened 8 years ago
Closed 7 years ago
#831 closed Bug / Defect ( fixed-external )
Crash on second client connection
| Reported by: | Rottman3D | Owned by: | Steffan Karger |
|---|---|---|---|
| Priority: | major | Milestone: | |
| Component: | Crypto | Version: | OpenVPN 2.4.0 (Community Ed) |
| Severity: | Not set (select this one, unless your'e a OpenVPN developer) | Keywords: | solaris , aes-gcm , aead , crash |
| Cc: |
Description
After upgrading to 2.4 the server runs fine for the first client connection. Upon the second client connecting OpenVPN server crashes. Server is using the kaizawa-tuntap-v1.3.2-4 tun driver which had no problems supporting several clients under 2.3. Server does use user/password authentication. Server is running Solaris 11.3.
Attachments (1)
Change History (7)
comment:1 Changed 8 years ago by
comment:2 Changed 8 years ago by
I have updated to 2.4.2 and still have the same problem. I have attached the log (verb 3), the only thing that stands out is "Could not determine IPv4/IPv6 protocol. Using AF_INET6". This is an IPv4 Network, but this could be a red herring.
comment:3 Changed 7 years ago by
Recreating the certs with the newer SHA algorithms instead of MD5 solved this issue. Currently working running on 2.4.5.
comment:4 Changed 7 years ago by
| Keywords: | solaris aes-gcm aead crash added |
|---|
Ah. I think I know what the problem was. AES-GCM is broken on
OpenSolaris?
due to "their OpenSSL library is miscompiled" - there was a thread about that on he openvpn-devel list:
https://www.mail-archive.com/openvpn-devel@lists.sourceforge.net/msg15340.html
... SHA vs. MD5 should not have any influence on this, but maybe you also moved the client to a different --cipher, disabled NCP, or installed a fixed OpenSSL as part of an
OpenSolaris?
update in the meantime?
What does "pkg list entire" print? The thread says that 11.2 FCS has the issue...
The AF_INET* bit is a red herring indeed :)
comment:5 follow-up: 6 Changed 7 years ago by
Entire package is 0.5.11-0.175.3.28.0.4.0
I did not change the cipher but I do install new versions of openssl as new packages are released. I know in the past I had to compile openssl by hand to get some headers that Oracle decided we did not need so I can't rule out a broken openssh. Though running 2.3.x always worked while 2.4 did not.
comment:6 Changed 7 years ago by
| Component: | Networking → Crypto |
|---|---|
| Owner: | set to Steffan Karger |
| Resolution: | → fixed-external |
| Status: | new → closed |
Replying to
Rottman3D
:
Entire package is 0.5.11-0.175.3.28.0.4.0
That sounds like you got the update... Casper wrote that "3.22" is the "bad" version.
I did not change the cipher but I do install new versions of openssl as new packages are released. I know in the past I had to compile openssl by hand to get some headers that Oracle decided we did not need so I can't rule out a broken openssh. Though running 2.3.x always worked while 2.4 did not.
That's because 2.3 did not support AES-GCM (AEAD) modes yet... new feature in 2.4.
Our configure script detects if the functions are there, but does not actually *test* them - and then, on usage, there is a null pointer access (inside Solaris-OpenSSL) and *bam* crash.
So, by upgrading OpenSSL, you actually found and fixed the problem :-)
Just for reference should someone else bump into this and find the ticket by googling: the fix is "upgrade OpenSSL", but one possible workaround for 2.4 is to disable the auto-upgrade of ciphers to AEAD by either configuring
--ncp-disable
*or* set up a different
--ncp-ciphers
list (like,
--ncp-ciphers AES-256-CBC
- but to make that work, all clients need to have this configured as well).
I'm closing this ticket now, with "fixed-external", because that's what it is :)
Can you provide a log file, please (--verb 3)? We don't regularily test the server side on (Open)Solaris, but I do not think anything in the server code is platform dependent enough to crash...
Please do also give 2.4.1 a try (to be released today).