Runtime: SSLv3_method not defined in file libssl.so.1.0.0

[raphi011]

Hi! I'm trying to access an SQL Server via EF on Arch Linux and the following error occurs.

Exception message:

/opt/dotnet/dotnet: relocation error: /opt/dotnet/shared/Microsoft.NETCore.App/1.1.0/System.Security.Cryptography.Native.OpenSsl.so: symbol SSLv3_method, version OPENSSL_1.0.0 not defined in file libssl.so.1.0.0 with link time reference

I know Arch Linux is not supported but maybe you guys have a hint so I may be able to fix this.

Steps to reproduce

Execute an arbitrary EF statement

Further technical details

EF Core version: 1.1.0
Database Provider: Microsoft.EntityFrameworkCore.SqlServer
Operating system: Arch Linux
IDE: (e.g. Visual Studio Code)

[karelz]

Do you have the right version of OpenSSL? Looks like it is missing a method ...

[bartonjs]

Arch must have compiled it without SSLv3 (old) support, but the distro we actually compiled that native asset for did have it.

Recompiling the native libraries for arch should fix the problem, but that's a DIY thing.

[jorgemota]

I am having the same issue, this was working a on november.. and now got this
/opt/dotnet/dotnet: relocation error: /opt/dotnet/shared/Microsoft.NETCore.App/1.1.0/System.Security.Cryptography.Native.OpenSsl.so: symbol SSLv3_method, version OPENSSL_1.0.0 not defined in file libssl.so.1.0.0 with link time reference

Only occurs when connecting to sql server (latest version on linux, and SQL Server 2012 )

Cannot find anything on how fix it on arch :(

[jorgemota]

I got this working again.. but I am not sure of problems with my solutions:
downloaded this file to some folder (/tmp/sslv3)
https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/openssl&id=4b82ed4285c7cb76caf6d75a015c5a7542c625d1

Edited and removed this no-ssl3 no-ssl3-method

downloaded this 3 files
https://git.archlinux.org/svntogit/packages.git/plain/trunk/ca-dir.patch?h=packages/openssl&id=4b82ed4285c7cb76caf6d75a015c5a7542c625d1

https://git.archlinux.org/svntogit/packages.git/plain/trunk/no-rpath.patch?h=packages/openssl&id=4b82ed4285c7cb76caf6d75a015c5a7542c625d1

https://git.archlinux.org/svntogit/packages.git/plain/trunk/ssl3-test-failure.patch?h=packages/openssl&id=4b82ed4285c7cb76caf6d75a015c5a7542c625d1

on terminal
cd /tmp/sslv3
makepkg
sudo pacman -U openssl-1.0.2.g-2-x86_64.pkg.tar.xz

Pacman tell me about downgrading openssl, but now I can connect from netcore to sql server without problems.

[jorgemota]

If someone want the latest version of openssl can try downloading all files from:
https://git.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/openssl
and remove from PKGBUILD this
no-ssl3-method

[raphi011]

Thanks, will try that later!

[hilts-vaughan]

Are there any updates on this? Quite a few distros no longer shipping SSL with this on: http://disablessl3.com/

Is there a good reason this is still required?

[bartonjs]

@hilts-vaughan We don't officially build for Arch. When running .NET Core on Arch you're using a .so built for a platform which still has SSL 3.0 enabled.

If you were to clone the corefx repository and ./build-native.sh on Arch, that would produce a System.Security.Cryptography.Native.OpenSsl.so which knew SSL 3.0 had been disabled by the platform at build time, and your error would go away.

[hilts-vaughan]

Hi @bartonjs

I totally get that. I was just wondering -- why is it that it tries to use SSLv3 in the first place? i.e: why select that particular algorithm?

[bartonjs]

SSLv3 only gets used when an application explicitly requests it, for example in sslStream.AuthenticateAsClientAsync("myolddevice.intranet", null, SslProtocols.Ssl3, true)

Note that in dotnet/corefx#15661 the filer is trying explicitly to communicate with old hardware which supports SSLv3 but not Tls1.0. So just blanket removing SSLv3 isn't viewed as a simple win by all users.

[jorgemota]

@bartonjs I got only the exception connecting to SQL Server from dotnet

[fdinardo]

@bartonjs thank you for the explanation. Did you think to provide a vagrant box using a tested Distro ready to run? like Ubuntu or fedora. I used the docker container for a while, but only for testing purpose. The advantage to have a vagrant box is for developing thanks to the shared file system, in this way I can write the code in my host and run it inside the box(guest)

@jorgemota your workaround didn't work for me with the very latest openssl.

[jorgemota]

@fdinardo can you post your PKG BUILD ? or download all files and zip it to share me?

[hilts-vaughan]

Please don't downgrade SSL to accomplish this. That's a security risk. If you want to do this, I wrote a guide on how under Arch by passing the current PKGBUILD every time you update:

http://vaughanhilts.me/blog/2017/02/06/openssl-with-sslv3-on-arch-linux-for-dot-net-core.html

Let me know if you have trouble.

[fdinardo]

@jorgemota Sure, but I think we should open a dedicated issue regarding dotnet on Arch specifically, Since this problem is due by the Arch's maintainers which (fortunately) got rid off SSLv3.

@hilts-vaughan Thanks for sharing your approach. Just let me understand more: what is the difference between your solution and jorgemota's one. Basically he made the patch manually while you are using a tool to achieve that. Am I right? It's only to learn new things... thanks.

[hilts-vaughan]

@jorgemota will be relying on old versions which will break every time you update. It's also an old version of OpenSSL provided above, so you will be open to security vulnerabilities as well that come with an older version.

Yes, mine is automatic and will apply the patch over the latest version every time you update.

[fdinardo]

@hilts-vaughan Is there actually a difference between customizepkg and customizepkg-git? I already have installed customizepkg, does it will do the same job?

[hilts-vaughan]

Yes, that will do fine.

[fdinardo]

@hilts-vaughan Thanks so much! This fixed the problem.

[hilts-vaughan]

Great. Happy development! @bartonjs feel free to link to my post for other Arch users if you guys want to at least post this information to avoid getting all the reports.

[bartonjs]

In .NET Core 2.0 the common release for Linux will use late binding for functions, and SSLv3_method is marked as one that we can handle being missing (which will result in an exception for the handful of people who explicitly request SSLv3 on a system where OpenSSL was built to not have it).

Since the next version will already be easier to work with on arch, and a couple different workarounds are already presented in this issue; I'm going to close this.

[winiciuscota]

Any suggestions on how to deal with this issue in 2019 while working on a legacy project(dotnet sdk 1.1)?

[bartonjs]

@winiciuscota The general answer will be that you need to build the native shim for crypto on your new platform (./build-native.sh after cloning down/checking-out the release/1.1.0 branch).

(If you're on an OS that we (Microsoft/DotNet) distribute packages for, and using that package (or using a docker container that we maintain) then that'd be something different... we shouldn't be producing broken packages)

.NET Core 2.1 (the current LTS release) shouldn't have many breaking changes over 1.1, and 1.1 goes out of support at the end of June (2019)... so I have to also recommend "upgrade to the newest LTS" as one of your remediation paths.