SSL routines:SSL_CTX_new:library has no ciphers

[VojtechVitek]

Hi,

First of all, thank you for the openfortivpn project! Love it. Well done!

Now onto my question: My openfortivpn 1.15.0 (OpenWRT) VPN connection dies with the following error every day after running 12+ hours:

ERROR:  SSL_CTX_new: error:140A90A1:SSL routines:SSL_CTX_new:library has no ciphers
INFO:   Could not log out.
ERROR:  SSL_CTX_new: error:140A90A1:SSL routines:SSL_CTX_new:library has no ciphers
INFO:   Closed connection to gateway.
ERROR:  SSL_CTX_new: error:140A90A1:SSL routines:SSL_CTX_new:library has no ciphers
INFO:   Could not log out.
ERROR:  SSL_CTX_new: error:140A90A1:SSL routines:SSL_CTX_new:library has no ciphers
INFO:   Closed connection to gateway.

Do you folks have any suggestions how could I make this go away? How can I make sure I have "enough ciphers"?

1. I tried to explicitly pass a cipher via --cipher-list= argument, but it didn't help. I got the cipher from openssl s_client -connect MY-SERVER-ADDR:443.
2. Then, I even tried --insecure-ssl argument (I knew it was not the greatest idea) but it didn't help either.

# openfortivpn --version
1.15.0

# uname -a
Linux wrt 4.14.195 #0 Sun Sep 6 16:19:39 2020 mips GNU/Linux

# ldd /usr/sbin/openfortivpn
	/lib/ld-musl-mips-sf.so.1 (0x77eb6000)
	libssl.so.1.1 => /usr/lib/libssl.so.1.1 (0x77e36000)
	libcrypto.so.1.1 => /usr/lib/libcrypto.so.1.1 (0x77c5c000)
	libc.so => /lib/ld-musl-mips-sf.so.1 (0x77eb6000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x77c38000)

Any help appreciated. Thanks!

Vojtech

[DimitriPapadopoulos]

If the connection dies after 12 hours, I suspect this might be a FortiGate timeout (server side) in which case you cannot do anything about it. But then the question would be why the error message is totally unrelated.

We need to clarify a few things:

• I understand openfortivpn works fine at first, then dies after 12 hours. Does it emit the above cipher-related error messages when disconnecting?
• How do you run openfortivpn? Can you you send the (sanitised) command line and or config file? Are you using the --persistent option?

My suggestion would be to test openfortivpn from a Linux machine. Does openfortivpn die too on Linux? If so does it emit the same cipher-related error messages?

[VojtechVitek]

I understand openfortivpn works fine at first, then dies after 12 hours. Does it emit the above cipher-related error messages when disconnecting?

Correct. Last time it ran for about 18h successfully and then it died with this error message ERROR: SSL_CTX_new: error:140A90A1:SSL routines:SSL_CTX_new:library has no ciphers. I don't think it was a server-side kick out. Let me measure it properly and I'll report back.

How do you run openfortivpn? Can you you send the (sanitised) command line and or config file? Are you using the --persistent option?

I run
$ openfortivpn --persistent=1

Should I try without the --persistent flag too?

Does openfortivpn die too on Linux?

I do run it on Linux. Linux wrt 4.14.195 #0 Sun Sep 6 16:19:39 2020 mips GNU/Linux
Perhaps, I can try to reproduce this on MacOS if that's any useful.

[DimitriPapadopoulos]

Ah, you're right, I was actually thinking of testing on a desktop or laptop with CentOS or Ubuntu. OpenWRT is a special case, the libraries are minimal libraries with possibly important differences compared to desktop GNU/Linux machines. It's a question of libraries - not kernel.

I believe there are two issues here:

1. openfortivpn dies after a few hours and I suspect this is related to a timeout somewhere along the path to the VPN SSL gateway. You might want to enable verbose logging with -v and also log PPP errors using --pppd-log.
2. Authentication works the first time and then fails the second time. I know --persistent works with passwords - but maybe not with other authentication methods. How do you authenticate? Can you send the (sanitised) config file? I suspect you're using a certificate for authentication and the certificate is not properly sent to the VPN gateway the second time, or something like that.

I had always considered --persistent is a bad idea because it can be easily implemented using a script, a systemd option or other mechanisms. It adds complexity and substantial maintenance burden to openfortivpn which wasn't written with such a mechanism in mind in the first place.

[VojtechVitek]

1. Thanks, I'll try the verbose debugging options and will report back.

2. host = my-hostname
   port = 443
   username = my-username
   password = *******
   trusted-cert = xxxx07b9210e7251a6b5b66aaab0000c253440bffc613dd665xx938558ayyyyy
   

I had always considered --persistent is a bad idea

Oh, I thought it kept the 2FA session/token somehow. Does it not? If not, I agree it's useless.

[DimitriPapadopoulos]

I understand you are using password authentication, so --persistent should work in you case. The password is not a one-time password, is it?

And you are correct again, in an ideal world openfortivpn should attempt to re-use the existing cookie before attempting a new round of authentication. It currently doesn't and I had opened issue #791 as an enhancement proposal. Anyway, the current implementation (with a new round of authentication) should work if your credentials are a username/password pair. Besides, as pointed out elsewhere the cookie would probably be invalid after a disconnection, especially after a server-side time out.

[VojtechVitek]

Our VPN server is guarded by 2FA. So, when I run openfortivpn, it asks me to submit a one-time token interactively before creating a VPN tunnel.

1. So, yes I have username+password stored in a config file.
2. But then there's an extra step of 2FA protection, prompting me to Please enter one-time password:.

[DimitriPapadopoulos]

OK, then I guess it is expected --persistent currently fails in this context. Depending on why the openfortivpn connection dies, the cookie might have been invalidated by the VPN gateway anyway. In such a case, even a better implementation such as described in #791 would fail to reconnect without prompting again for the one-time password.

Even if --persistent cannot possibly work with the current implementation, we should investigate why openfortivpn disconnects. Perhaps it can be avoided, perhaps it can also give valuable insight on implementing #791 in the future.

Finally, the OpenSSL error message doesn't make much sense to me at this point. Perhaps there's an additional issue here, which might be caused by anything such as OpenSSL library mismatches. I really don't know:

ERROR:  SSL_CTX_new: error:140A90A1:SSL routines:SSL_CTX_new:library has no ciphers

The error message originates here, in ssl_connect():
https://github.com/adrienverge/openfortivpn/blob/c3ae8b9/src/tunnel.c#L867-L872

The info message originates here, in run_tunnel(), just after ssl_connect() has failed:
https://github.com/adrienverge/openfortivpn/blob/c3ae8b9/src/tunnel.c#L1180-L1185

[VojtechVitek]

Please see the attached logs from

time openfortivpn --persistent=1 -v --pppd-log=pppd-log.txt | tee fortivpn-log.txt

pppd-log.txt
fortivpn-log.txt

[DimitriPapadopoulos]

Initially openfortivpn seems to die upon:

DEBUG:  Error reading from SSL connection (Protocol violation with EOF).

That's a first issue that needs to be investigated. This is not necessarily an openfortivpn error.

Then on the first attempt to reconnect after the above failure:

ERROR:  Could not authenticate to gateway. Please check the password, client certificate, etc.
DEBUG:  HTTP status code 405
INFO:   Closed connection to gateway.

I suppose that's because openfortivpn does not implement the 2FA step. Can you confirm? This probably needs to be investigated and possibly fixed in openfortivpn.

The above attempt is repeated 103 times, but the last attempts end differently:

ERROR:  Could not authenticate to gateway. Please check the password, client certificate, etc.
DEBUG:  SSL error -4
INFO:   Closed connection to gateway.

and:

DEBUG:  Error reading from SSL connection (Protocol error).

And then the next round goes wrong with the error message you had initially reported:

ERROR:  SSL_connect: error:14161044:SSL routines:state_machine:internal error
You might want to try --insecure-ssl or specify a different --cipher-list

I suggest we do not investigate this for now. As I said it could be anything, perhaps even an internal OpenSSL error caused by the multiple failures above.

[DimitriPapadopoulos]

Again I believe it would help if you could test from a GNU/Linux desktop machine and see if openfortivpn behaves differently. I have a gut feeling this could be related to an OpenSSL library mixup or some other issue with OpenWrt.

[VojtechVitek]

I will try, but I can't promise when exactly. Thanks for your support.

[VojtechVitek]

Reporting back, now without the --persistent flag, but still from OpenWRT:

DEBUG:  gateway ---> pppd (42 bytes)
DEBUG:  pppd ---> gateway (42 bytes)
DEBUG:  gateway ---> pppd (58 bytes)
DEBUG:  pppd ---> gateway (42 bytes)
DEBUG:  Error reading from SSL connection (Protocol violation with EOF).
INFO:   Cancelling threads...
INFO:   Cleanup, joining threads...
DEBUG:  disconnecting
INFO:   Setting ppp0 interface down.
INFO:   Restoring routes...
DEBUG:  ip route del to XXX.XXX.XX.XXX/255.255.255.255 via 192.168.0.1 dev eth0.2
INFO:   Removing VPN nameservers...
DEBUG:  Deleting "nameserver AA.AAA.A.AAA" from /etc/resolv.conf.
DEBUG:  Deleting "nameserver BB.BBB.B.BBB" from /etc/resolv.conf.
DEBUG:  Deleting "search vci.local" from /etc/resolv.conf.
DEBUG:  Waiting for pppd to exit...
DEBUG:  waitpid: pppd exit status code 5
ERROR:  pppd: Terminated because it was sent a SIGINT, SIGTERM or SIGHUP signal.
INFO:   Terminated pppd.
INFO:   Closed connection to gateway.
DEBUG:  server_addr: XXX.XXX.XX.XXX
DEBUG:  server_port: 443
DEBUG:  gateway_addr: YYY.YYY.YY.YYY
DEBUG:  gateway_port: 443
DEBUG:  Setting cipher list to: HIGH:!aNULL:!kRSA:!PSK:!SRP:!MD5:!RC4
DEBUG:  Setting minimum protocol version to: 0x303.
DEBUG:  Gateway certificate validation failed.
DEBUG:  Gateway certificate digest found in white list.
INFO:   Logged out.
real    21h 10m 30s
user    0m 3.64s
sys     0m 4.50s

[DimitriPapadopoulos]

Still this error:

DEBUG:  Error reading from SSL connection (Protocol violation with EOF).

I suspect this is an OpenWRT issue.

You really need to compare with a Linux machine.

[VojtechVitek]

I never hit this issue on Darwin. Though, I haven't tried Linux.

[dlenski]

Correct. Last time it ran for about 18h successfully and then it died with this error message ERROR: SSL_CTX_new: error:140A90A1:SSL routines:SSL_CTX_new:library has no ciphers. I don't think it was a server-side kick out. Let me measure it properly and I'll report back.

Is it possible that the server is attempting to re-handshake or re-negotiate the TLS session?

Given this line (DEBUG: Setting minimum protocol version to: 0x303.) it's clear that you must be connecting with at least TLS v1.2 (0x303 == TLS v1.2). Is it TLS 1.2 or 1.3?