Opened 4 years ago

Closed 5 months ago

#572 closed Bug / Defect (worksforme)

Error connecting using ECDSA certificates

Reported by: corrideat Owned by:
Priority: major Milestone:
Component: Generic / unclassified Version: OpenVPN git master branch (Community Ed)
Severity: Not set (select this one, unless your'e a OpenVPN developer) Keywords:
Cc: Steffan Karger

Description

I attempted to replace my current OpenVPN RSA certificates with EC cryptography because of its greater strength at much smaller key sizes. However, I run into some connectivity issues, which I am certain are unrelated to configuration as it works just fine for RSA certificates.

I control both the server and the client, so I am including the minimal configuration I created to reproduce the issue below:

# SERVER
auth none
ca /etc/openvpn/ssl/ca.crt
cert /etc/openvpn/ssl/xxxx.crt
client-to-client
dev tun
dh dh4096.pem
ifconfig-pool-persist ipp.txt
keepalive 10 120
key /etc/openvpn/ssl/xxxx.key  # This file should be kept secret
max-clients 10
mute 20
persist-key
persist-tun
port 1194
proto tcp
server 172.16.54.0 255.255.255.0
status openvpn-status.log
tls-server
verb 4
 
 
# Client
auth none
ca /etc/openvpn/ca.crt
cert /etc/openvpn/client.crt
client
dev tun
key client.pem
persist-key
persist-tun
proto tcp
remote 106.186.123.168 1194
nobind
verb 9
tls-client

My certificate looks like this:

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: X (0xX)
    Signature Algorithm: ecdsa-with-SHA1
        Issuer: XXXX
        Validity
            Not Before: Jul  1 00:00:00 2015 GMT
            Not After : Jan  1 00:00:00 2022 GMT
        Subject: XXXXX
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (521 bit)
                pub: 
                    04:01:...
                ASN1 OID: secp521r1
        X509v3 extensions:
            X509v3 Basic Constraints: 
                CA:FALSE
            Netscape Cert Type: 
                SSL Server
            X509v3 Subject Key Identifier: 
                4D:66:B2:...
            X509v3 Authority Key Identifier: 
4

    Signature Algorithm: ecdsa-with-SHA1
         30:81:88:....

Attachments (3)

client.log (98.6 KB) - added by corrideat 4 years ago.
Client Connection Log
server.log (2.7 KB) - added by corrideat 4 years ago.
Server Connection Log
server-verbose.log (122.2 KB) - added by corrideat 4 years ago.

Download all attachments as: .zip

Change History (11)

Changed 4 years ago by corrideat

Attachment: client.log added

Client Connection Log

Changed 4 years ago by corrideat

Attachment: server.log added

Server Connection Log

comment:1 Changed 4 years ago by Gert Döring

Cc: Steffan Karger added

To my uneducated eye, it looks like the server receives something it does not like, and closes the TCP socket - so the client gets "Connection reset" and retries. No idea why that might be, though... could you bump up the server log level a bit?

Handing the ticket to syzzer, because he understands EC crypto :)

comment:2 Changed 4 years ago by Steffan Karger

Unfortunately, I do not see the problem in these logs.

A couple of questions:

  • Are both client and server running git-master?
  • Can you add a complete and higher-verbosity server log too? (--verb 9, like the client, is ok)
  • Why on earth do you use 'auth none'. If you are looking for a secure setup, you are certainly not achieving that with this setting.
Last edited 4 years ago by Steffan Karger (previous) (diff)

comment:3 Changed 4 years ago by corrideat

Are both client and server running git-master?

Yes.

Can you add a complete and higher-verbosity server log too? (--verb 9, like the client, is ok)

Added.

Why on earth do you use 'auth none'. If you are looking for a secure setup, you are certainly not achieving that with this setting.

Because I didn't want the setting to interfere, as before I was using RSA-SHA256. However, I experimented with different values and I got the same results.

Note: if I swap the certificates/keys with RSA certificates (which I've been using before I decided to go with ECC, these connection issues go away. So, I'm thinking it's safe to say this is a TLS issue.)

Changed 4 years ago by corrideat

Attachment: server-verbose.log added

comment:4 in reply to:  3 Changed 4 years ago by Steffan Karger

Replying to corrideat:

Can you add a complete and higher-verbosity server log too? (--verb 9, like the client, is ok)

Added.

Thanks. Though these do not show any of the hints I was hoping to see (specifically, some openssl error). So at this point, there's just hunches. Have you tried using a different curve? If possible, try P-384, it is the one I did my tests with. Also, you could try using a larger certificate hash, at least SHA256.

Why on earth do you use 'auth none'. If you are looking for a secure setup, you are certainly not achieving that with this setting.

Because I didn't want the setting to interfere, as before I was using RSA-SHA256. However, I experimented with different values and I got the same results.

Good, just make sure to never use auth none in production. auth applies to digest used for the data channel, and if used, openvpn's tls-auth. Disabling tls-auth during tests wrt TLS makes sense, but disabling auth will not make a difference if tls-auth is not used.

Note: if I swap the certificates/keys with RSA certificates (which I've been using before I decided to go with ECC, these connection issues go away. So, I'm thinking it's safe to say this is a TLS issue.)

I sure seems that way, yes.

comment:5 Changed 3 years ago by Gert Döring

So, how do we proceed with this?

comment:6 Changed 3 years ago by Steffan Karger

This is working just fine on a number of setups I have here.

To figure out what is failing here, could you:

  1. Post the client and server platforms and openssl versions
  2. Provide a key/certificate test set (CA+client+server) that fails for you (just to be absolutely clear: this should obviously not be certs you would ever use).

That might help me reproduce.

comment:7 in reply to:  2 Changed 5 months ago by MichaelCowles

SPAM

Last edited 5 months ago by Gert Döring (previous) (diff)

comment:8 Changed 5 months ago by Gert Döring

Resolution: worksforme
Status: newclosed

since all we got in the last 3 years is a single SPAM *and* this is working for people, closing as "worksforme"

Note: See TracTickets for help on using tickets.