Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make SSL_set1_host and SSL_add1_host handle IP addresses #9201

Closed
wants to merge 4 commits into from

Conversation

@dwmw2
Copy link
Contributor

@dwmw2 dwmw2 commented Jun 20, 2019

We have SSL_set1_hostname() already. It would be reasonable for developers to assume that it can be used for IP literals. It can't. Add the functions that can.

Then use them to fix the sconnect demo, which was failing for IP literals.

Checklist
  • documentation is added or updated
  • tests are added or updated
@dwmw2 dwmw2 force-pushed the dwmw2:ssl_add_ip branch Jun 20, 2019
@dwmw2
Copy link
Contributor Author

@dwmw2 dwmw2 commented Jun 24, 2019

The alternative, of course, is to let SSL_set1_host() accept IP literals and silently Do The Right Thing with them, calling X509_VERIFY_PARAM_set1_ip_asc(). That would conform to the Principle of Least Surprise for callers.

I didn't do that that because I was focused on the internal implementation details and instead added SSL_set1_ip(), to make it consistent with the underlying X509_VERIFY_PARAM_* functionality.

But that's the mistake we always make — 'designing' an API based on inward-looking implementation details rather than considering how the user will get it wrong. So now I'm wondering if that was the wrong choice.

Especially since the BIO_set_conn_hostname() call does accept an IP literal in the hostname, and we end up with an inconsistency in the user-facing high level APIs. We basically designed an overall set of APIs so inconsistent and hard to use that our own demo didn't get it right, because one OpenSSL function accepts an IP literal in the hostname field but the other one does not.

So it might make sense to just make SSL_set1_host() take IP literals instead of what I did here. Please advise, and I'll do that if it's the route you prefer to take.

@dwmw2
Copy link
Contributor Author

@dwmw2 dwmw2 commented Aug 14, 2019

Ping?

@dwmw2 dwmw2 force-pushed the dwmw2:ssl_add_ip branch Sep 4, 2019
@levitte
Copy link
Member

@levitte levitte commented Oct 10, 2019

Sorry that this took so long even looking at. There's a lot going on right now...

@dwmw2 dwmw2 force-pushed the dwmw2:ssl_add_ip branch Oct 11, 2019
@mspncp
Copy link
Contributor

@mspncp mspncp commented Oct 12, 2019

The alternative, of course, is to let SSL_set1_host() accept IP literals and silently Do The Right Thing with them, calling X509_VERIFY_PARAM_set1_ip_asc(). That would conform to the Principle of Least Surprise for callers.

@levitte wouldn’t this be a better solution? ( see @dwmw2‘s comment above).

@dwmw2
Copy link
Contributor Author

@dwmw2 dwmw2 commented Oct 12, 2019

I can provide that in a follow-up commit. Should X509_VERIFY_PARAM_set1_host() work the same way?

It has the advantage that it can theoretically be backported to older release streams to fix this behaviour there, because it doesn't rely on adding the separate new function.

(Not that there are DSO compatibility reasons for the policy of not adding symbols in a stable release stream, but that's a different discussion.)

@levitte
Copy link
Member

@levitte levitte commented Oct 12, 2019

Having the _host() functions check if they can parse it as an IP address and handling it as such is a smart idea, yeah.

@dwmw2
Copy link
Contributor Author

@dwmw2 dwmw2 commented Oct 13, 2019

Will do. They should handle the [] around IPv6 literals; I'll do that too.

Do we even want to add SSL_set _ip_asc() in that case?

@mspncp
Copy link
Contributor

@mspncp mspncp commented Oct 13, 2019

Do we even want to add SSL_set _ip_asc() in that case?

If SSL_set1_host() accepts ip addresses, then SSL_set1_ip_asc() is dispensible IMHO.

I would also suggest to rename SSL_set1_ip() to SSL_set1_host_ip(), to emphasize that it is an "overloaded" version of SSL_set1_host() (if I understood you right).

@dwmw2
Copy link
Contributor Author

@dwmw2 dwmw2 commented Oct 13, 2019

I was going to ditch that too, potentially leaving the PR entirely applicable to older stable releases. But I can keep SSL_set1_host_ip() for the master version if you prefer.

@mspncp
Copy link
Contributor

@mspncp mspncp commented Oct 13, 2019

But I can keep SSL_set1_host_ip() for the master version if you prefer.

I'm not deep enough into the details, so I'll let @levitte or others decide that.

@levitte
Copy link
Member

@levitte levitte commented Oct 13, 2019

If SSL_set1_host is made to accept IP addresses too, I see no reason to add any other function, unless you see a reason to enforce IP address only.

@dwmw2
Copy link
Contributor Author

@dwmw2 dwmw2 commented Oct 13, 2019

IP address only is achieved by passing only (a textual representation of) an IP address to SSL_set1_host()

@levitte
Copy link
Member

@levitte levitte commented Oct 13, 2019

The key word was "enforce", i.e. if there's a reason to call a function that only accepts IP addresses. I can't think of a reason to do so, but I might simply not know.

@dwmw2
Copy link
Contributor Author

@dwmw2 dwmw2 commented Oct 13, 2019

Ah, right. Yeah, I can't see a reason to do that either.

Making X509_VERIFY_PARAM transparently accept IP addresses anywhere it accepts hostnames is slightly non-trivial as there can be only one vpm->ip which must match, while there's a list of hostnames of which only one needs to match. I could change that but it's more intrusive. I think I'll just fix up SSL_set1_host() which is the newish API, while leaving X509_VERIFY_PARAM as it was.

So SSL_set1_host() will effectively just call X509_VERIFY_PARAM_set1_ip_asc() || X509_VERIFY_PARAM_set1_host() — i.e. if it works as an IP address, fine. Else it's a hostname.

@dwmw2 dwmw2 force-pushed the dwmw2:ssl_add_ip branch Oct 14, 2019
@dwmw2
Copy link
Contributor Author

@dwmw2 dwmw2 commented Oct 14, 2019

OK, how's this? It's slightly asymmetric because X509_VERIFY_PARAM treats IP addresses very differently to hostnames — it has a stack of the latter, while there can only be one IP address and you can't even clear the IP address once it's set.

But the set1_ip_asc() || set1_host() approach does cover the major use case correctly, and makes it harder for applications to get it wrong.

I do still need to patch the sconnect demo because a simple "truncate at the first colon" doesn't work for IPv6 literals; it should be using BIO_get_conn_hostname() since the BIO already did all that properly, including stripping the [] from around it.

In the general case, something will always need to have extracted the IPv6 literal from within the [] so I think it's OK for SSL_set1_host() to require that the IPv6 addresses don't have the [] and I haven't attempted to cope with that.

ssl/ssl_lib.c Show resolved Hide resolved
@mspncp
Copy link
Contributor

@mspncp mspncp commented Nov 8, 2019

While playing around with the sconnect demo, I noticed that the compiler complains about the deprecated function SSL_CTX_load_verify_locations(), see issue #10392.

@mspncp
Copy link
Contributor

@mspncp mspncp commented Nov 8, 2019

@dwmw2 unfortunately there is not much documentation about the sconnect demo. A (very) short glance at the source code gave me the impression that I could run sconnect against server-conf out-of-the box without much extra configuration. So I followed the quick instruction in the Makefile to build the binaries and ran

msp@msppc:~/src/openssl/demos/bio$ LD_LIBRARY_PATH=../.. ./server-conf 

in one console, after which netstat would show a listening socket at port 4433:

msp@msppc:~$ netstat -an  | grep -w 4433
tcp        0      0 0.0.0.0:4433            0.0.0.0:*               LISTEN     

However, when I ran sconnect in another console, I got the following error message.

msp@msppc:~/src/openssl/demos/bio$ LD_LIBRARY_PATH=../.. ./sconnect 
write DELAY
00:72:61:29:82:7F:00:00:error:system library:conn_state:Connection refused:crypto/bio/bss_conn.c:189:calling connect(localhost, 4433)
00:72:61:29:82:7F:00:00:error:BIO routines:conn_state:nbio connect error:crypto/bio/bss_conn.c:192:

What am I missing? Could you please give me a quick introduction how to use the demo?

@mspncp
Copy link
Contributor

@mspncp mspncp commented Nov 8, 2019

Ok, the previous failure seems to be an IPv6 problem. Apparently the sconnect demo connects to localhost using IPv6, while the server only listens only IPv4 addresses.

(Note: both tcpdump captures below are attached as sconnect.zip.)

msp@msppc:~$ tcpdump -r sconnect-01.pcap -vv

reading from file sconnect-01.pcap, link-type EN10MB (Ethernet)
18:37:26.204210 IP6 (flowlabel 0xdabe0, hlim 64, next-header TCP (6) payload length: 40) localhost.35022 > localhost.4433: Flags [S], cksum 0x0030 (incorrect -> 0x2a78), seq 1463511547, win 43690, options [mss 65476,sackOK,TS val 3619898801 ecr 0,nop,wscale 7], length 0
18:37:26.204216 IP6 (flowlabel 0x02f56, hlim 64, next-header TCP (6) payload length: 20) localhost.4433 > localhost.35022: Flags [R.], cksum 0x001c (incorrect -> 0x5478), seq 0, ack 1463511548, win 0, length 0

If I use my hostname instead, I get a handshake failure instead:

msp@msppc:~/openssl/openssl/demos/bio$ LD_LIBRARY_PATH=../.. ./sconnect msppc:4433
write DELAY
write DELAY
00:72:58:12:4F:7F:00:00:error:SSL routines::sslv3 alert handshake failure:ssl/record/rec_layer_s3.c:1597:SSL alert number 40

The server side terminates with the following error,

msp@msppc:~/openssl/openssl/demos/bio$ LD_LIBRARY_PATH=../.. ./server-conf 
00:E2:A6:67:B1:7F:00:00:error:SSL routines::no suitable signature algorithm:ssl/t1_lib.c:2810:

msp@msppc:~/openssl/openssl/demos/bio$ echo $?
1

and port 4433 remains in TIME_WAIT state for a while:

msp@msppc:~/openssl/openssl/demos/bio$ netstat -an | grep -w 4433
tcp        0      0 172.16.15.99:4433       172.16.15.99:55846      TIME_WAIT  

The tcpdump output is not very helpful...

msp@msppc:~$ tcpdump -r sconnect-02.pcap -vv

reading from file sconnect-02.pcap, link-type EN10MB (Ethernet)
18:41:49.057466 IP (tos 0x0, ttl 64, id 3355, offset 0, flags [DF], proto TCP (6), length 60)
    172.16.15.99.55754 > 172.16.15.99.4433: Flags [S], cksum 0x7715 (incorrect -> 0xab32), seq 3212657268, win 43690, options [mss 65495,sackOK,TS val 1601057948 ecr 0,nop,wscale 7], length 0
18:41:49.057474 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    172.16.15.99.4433 > 172.16.15.99.55754: Flags [S.], cksum 0x7715 (incorrect -> 0x443f), seq 2670867365, ack 3212657269, win 43690, options [mss 65495,sackOK,TS val 1601057948 ecr 1601057948,nop,wscale 7], length 0
18:41:49.057482 IP (tos 0x0, ttl 64, id 3356, offset 0, flags [DF], proto TCP (6), length 52)
    172.16.15.99.55754 > 172.16.15.99.4433: Flags [.], cksum 0x770d (incorrect -> 0x1684), seq 1, ack 1, win 342, options [nop,nop,TS val 1601057948 ecr 1601057948], length 0
18:41:50.057669 IP (tos 0x0, ttl 64, id 3357, offset 0, flags [DF], proto TCP (6), length 355)
    172.16.15.99.55754 > 172.16.15.99.4433: Flags [P.], cksum 0x783c (incorrect -> 0xe72a), seq 1:304, ack 1, win 342, options [nop,nop,TS val 1601058949 ecr 1601057948], length 303
18:41:50.057681 IP (tos 0x0, ttl 64, id 31945, offset 0, flags [DF], proto TCP (6), length 52)
    172.16.15.99.4433 > 172.16.15.99.55754: Flags [.], cksum 0x770d (incorrect -> 0x0d7b), seq 1, ack 304, win 350, options [nop,nop,TS val 1601058949 ecr 1601058949], length 0
18:41:50.057802 IP (tos 0x0, ttl 64, id 31946, offset 0, flags [DF], proto TCP (6), length 59)
    172.16.15.99.4433 > 172.16.15.99.55754: Flags [P.], cksum 0x7714 (incorrect -> 0xcb66), seq 1:8, ack 304, win 350, options [nop,nop,TS val 1601058949 ecr 1601058949], length 7
18:41:50.057808 IP (tos 0x0, ttl 64, id 3358, offset 0, flags [DF], proto TCP (6), length 52)
    172.16.15.99.55754 > 172.16.15.99.4433: Flags [.], cksum 0x770d (incorrect -> 0x0d7c), seq 304, ack 8, win 342, options [nop,nop,TS val 1601058949 ecr 1601058949], length 0
18:41:50.058959 IP (tos 0x0, ttl 64, id 31947, offset 0, flags [DF], proto TCP (6), length 52)
    172.16.15.99.4433 > 172.16.15.99.55754: Flags [F.], cksum 0x770d (incorrect -> 0x0d72), seq 8, ack 304, win 350, options [nop,nop,TS val 1601058950 ecr 1601058949], length 0
18:41:50.099436 IP (tos 0x0, ttl 64, id 3359, offset 0, flags [DF], proto TCP (6), length 52)
    172.16.15.99.55754 > 172.16.15.99.4433: Flags [.], cksum 0x770d (incorrect -> 0x0d51), seq 304, ack 9, win 342, options [nop,nop,TS val 1601058990 ecr 1601058950], length 0
18:41:51.058086 IP (tos 0x0, ttl 64, id 3360, offset 0, flags [DF], proto TCP (6), length 52)
    172.16.15.99.55754 > 172.16.15.99.4433: Flags [F.], cksum 0x770d (incorrect -> 0x0991), seq 304, ack 9, win 342, options [nop,nop,TS val 1601059949 ecr 1601058950], length 0
18:41:51.058113 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 52)
    172.16.15.99.4433 > 172.16.15.99.55754: Flags [.], cksum 0x05a2 (correct), seq 9, ack 305, win 350, options [nop,nop,TS val 1601059949 ecr 1601059949], length 0

...but luckily wireshark has a little brother for the console:

msp@msppc:~$ tshark -r sconnect-02.pcap -V -O tls

Frame 1: 74 bytes on wire (592 bits), 74 bytes captured (592 bits)
Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00)
Internet Protocol Version 4, Src: 172.16.15.99, Dst: 172.16.15.99
Transmission Control Protocol, Src Port: 55754, Dst Port: 4433, Seq: 0, Len: 0

Frame 2: 74 bytes on wire (592 bits), 74 bytes captured (592 bits)
Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00)
Internet Protocol Version 4, Src: 172.16.15.99, Dst: 172.16.15.99
Transmission Control Protocol, Src Port: 4433, Dst Port: 55754, Seq: 0, Ack: 1, Len: 0

Frame 3: 66 bytes on wire (528 bits), 66 bytes captured (528 bits)
Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00)
Internet Protocol Version 4, Src: 172.16.15.99, Dst: 172.16.15.99
Transmission Control Protocol, Src Port: 55754, Dst Port: 4433, Seq: 1, Ack: 1, Len: 0

Frame 4: 369 bytes on wire (2952 bits), 369 bytes captured (2952 bits)
Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00)
Internet Protocol Version 4, Src: 172.16.15.99, Dst: 172.16.15.99
Transmission Control Protocol, Src Port: 55754, Dst Port: 4433, Seq: 1, Ack: 1, Len: 303
Transport Layer Security
    TLSv1 Record Layer: Handshake Protocol: Client Hello
        Content Type: Handshake (22)
        Version: TLS 1.0 (0x0301)
        Length: 298
        Handshake Protocol: Client Hello
            Handshake Type: Client Hello (1)
            Length: 294
            Version: TLS 1.2 (0x0303)
            Random: 003335f1dcf634f5510411be9a24e849210c8787332cc9e5…
                GMT Unix Time: Feb  8, 1970 21:15:45.000000000 CET
                Random Bytes: dcf634f5510411be9a24e849210c8787332cc9e54b1e7bb1…
            Session ID Length: 32
            Session ID: 0ca448ecb7196c6c8f29283346291481a45a3543b62c014a…
            Cipher Suites Length: 62
            Cipher Suites (31 suites)
                Cipher Suite: TLS_AES_256_GCM_SHA384 (0x1302)
                Cipher Suite: TLS_CHACHA20_POLY1305_SHA256 (0x1303)
                Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 (0xc02c)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
                Cipher Suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 (0x009f)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9)
                Cipher Suite: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8)
                Cipher Suite: TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xccaa)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
                Cipher Suite: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 (0x009e)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 (0xc024)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028)
                Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 (0x006b)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 (0xc023)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027)
                Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 (0x0067)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014)
                Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039)
                Cipher Suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009)
                Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013)
                Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033)
                Cipher Suite: TLS_RSA_WITH_AES_256_GCM_SHA384 (0x009d)
                Cipher Suite: TLS_RSA_WITH_AES_128_GCM_SHA256 (0x009c)
                Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA256 (0x003d)
                Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA256 (0x003c)
                Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035)
                Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f)
                Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff)
            Compression Methods Length: 1
            Compression Methods (1 method)
                Compression Method: null (0)
            Extensions Length: 159
            Extension: ec_point_formats (len=4)
                Type: ec_point_formats (11)
                Length: 4
                EC point formats Length: 3
                Elliptic curves point formats (3)
                    EC point format: uncompressed (0)
                    EC point format: ansiX962_compressed_prime (1)
                    EC point format: ansiX962_compressed_char2 (2)
            Extension: supported_groups (len=22)
                Type: supported_groups (10)
                Length: 22
                Supported Groups List Length: 20
                Supported Groups (10 groups)
                    Supported Group: x25519 (0x001d)
                    Supported Group: secp256r1 (0x0017)
                    Supported Group: x448 (0x001e)
                    Supported Group: secp521r1 (0x0019)
                    Supported Group: secp384r1 (0x0018)
                    Supported Group: ffdhe2048 (0x0100)
                    Supported Group: ffdhe3072 (0x0101)
                    Supported Group: ffdhe4096 (0x0102)
                    Supported Group: ffdhe6144 (0x0103)
                    Supported Group: ffdhe8192 (0x0104)
            Extension: session_ticket (len=0)
                Type: session_ticket (35)
                Length: 0
                Data (0 bytes)
            Extension: encrypt_then_mac (len=0)
                Type: encrypt_then_mac (22)
                Length: 0
            Extension: extended_master_secret (len=0)
                Type: extended_master_secret (23)
                Length: 0
            Extension: signature_algorithms (len=48)
                Type: signature_algorithms (13)
                Length: 48
                Signature Hash Algorithms Length: 46
                Signature Hash Algorithms (23 algorithms)
                    Signature Algorithm: ecdsa_secp256r1_sha256 (0x0403)
                        Signature Hash Algorithm Hash: SHA256 (4)
                        Signature Hash Algorithm Signature: ECDSA (3)
                    Signature Algorithm: ecdsa_secp384r1_sha384 (0x0503)
                        Signature Hash Algorithm Hash: SHA384 (5)
                        Signature Hash Algorithm Signature: ECDSA (3)
                    Signature Algorithm: ecdsa_secp521r1_sha512 (0x0603)
                        Signature Hash Algorithm Hash: SHA512 (6)
                        Signature Hash Algorithm Signature: ECDSA (3)
                    Signature Algorithm: ed25519 (0x0807)
                        Signature Hash Algorithm Hash: Unknown (8)
                        Signature Hash Algorithm Signature: Unknown (7)
                    Signature Algorithm: ed448 (0x0808)
                        Signature Hash Algorithm Hash: Unknown (8)
                        Signature Hash Algorithm Signature: Unknown (8)
                    Signature Algorithm: rsa_pss_pss_sha256 (0x0809)
                        Signature Hash Algorithm Hash: Unknown (8)
                        Signature Hash Algorithm Signature: Unknown (9)
                    Signature Algorithm: rsa_pss_pss_sha384 (0x080a)
                        Signature Hash Algorithm Hash: Unknown (8)
                        Signature Hash Algorithm Signature: Unknown (10)
                    Signature Algorithm: rsa_pss_pss_sha512 (0x080b)
                        Signature Hash Algorithm Hash: Unknown (8)
                        Signature Hash Algorithm Signature: Unknown (11)
                    Signature Algorithm: rsa_pss_rsae_sha256 (0x0804)
                        Signature Hash Algorithm Hash: Unknown (8)
                        Signature Hash Algorithm Signature: Unknown (4)
                    Signature Algorithm: rsa_pss_rsae_sha384 (0x0805)
                        Signature Hash Algorithm Hash: Unknown (8)
                        Signature Hash Algorithm Signature: Unknown (5)
                    Signature Algorithm: rsa_pss_rsae_sha512 (0x0806)
                        Signature Hash Algorithm Hash: Unknown (8)
                        Signature Hash Algorithm Signature: Unknown (6)
                    Signature Algorithm: rsa_pkcs1_sha256 (0x0401)
                        Signature Hash Algorithm Hash: SHA256 (4)
                        Signature Hash Algorithm Signature: RSA (1)
                    Signature Algorithm: rsa_pkcs1_sha384 (0x0501)
                        Signature Hash Algorithm Hash: SHA384 (5)
                        Signature Hash Algorithm Signature: RSA (1)
                    Signature Algorithm: rsa_pkcs1_sha512 (0x0601)
                        Signature Hash Algorithm Hash: SHA512 (6)
                        Signature Hash Algorithm Signature: RSA (1)
                    Signature Algorithm: SHA224 ECDSA (0x0303)
                        Signature Hash Algorithm Hash: SHA224 (3)
                        Signature Hash Algorithm Signature: ECDSA (3)
                    Signature Algorithm: ecdsa_sha1 (0x0203)
                        Signature Hash Algorithm Hash: SHA1 (2)
                        Signature Hash Algorithm Signature: ECDSA (3)
                    Signature Algorithm: SHA224 RSA (0x0301)
                        Signature Hash Algorithm Hash: SHA224 (3)
                        Signature Hash Algorithm Signature: RSA (1)
                    Signature Algorithm: rsa_pkcs1_sha1 (0x0201)
                        Signature Hash Algorithm Hash: SHA1 (2)
                        Signature Hash Algorithm Signature: RSA (1)
                    Signature Algorithm: SHA224 DSA (0x0302)
                        Signature Hash Algorithm Hash: SHA224 (3)
                        Signature Hash Algorithm Signature: DSA (2)
                    Signature Algorithm: SHA1 DSA (0x0202)
                        Signature Hash Algorithm Hash: SHA1 (2)
                        Signature Hash Algorithm Signature: DSA (2)
                    Signature Algorithm: SHA256 DSA (0x0402)
                        Signature Hash Algorithm Hash: SHA256 (4)
                        Signature Hash Algorithm Signature: DSA (2)
                    Signature Algorithm: SHA384 DSA (0x0502)
                        Signature Hash Algorithm Hash: SHA384 (5)
                        Signature Hash Algorithm Signature: DSA (2)
                    Signature Algorithm: SHA512 DSA (0x0602)
                        Signature Hash Algorithm Hash: SHA512 (6)
                        Signature Hash Algorithm Signature: DSA (2)
            Extension: supported_versions (len=9)
                Type: supported_versions (43)
                Length: 9
                Supported Versions length: 8
                Supported Version: TLS 1.3 (0x0304)
                Supported Version: TLS 1.2 (0x0303)
                Supported Version: TLS 1.1 (0x0302)
                Supported Version: TLS 1.0 (0x0301)
            Extension: psk_key_exchange_modes (len=2)
                Type: psk_key_exchange_modes (45)
                Length: 2
                PSK Key Exchange Modes Length: 1
                PSK Key Exchange Mode: PSK with (EC)DHE key establishment (psk_dhe_ke) (1)
            Extension: key_share (len=38)
                Type: key_share (51)
                Length: 38
                Key Share extension
                    Client Key Share Length: 36
                    Key Share Entry: Group: x25519, Key Exchange length: 32
                        Group: x25519 (29)
                        Key Exchange Length: 32
                        Key Exchange: de6fcf44e0e77c15af1fa00391f4c74b5b5e049ce83373cb…

Frame 5: 66 bytes on wire (528 bits), 66 bytes captured (528 bits)
Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00)
Internet Protocol Version 4, Src: 172.16.15.99, Dst: 172.16.15.99
Transmission Control Protocol, Src Port: 4433, Dst Port: 55754, Seq: 1, Ack: 304, Len: 0

Frame 6: 73 bytes on wire (584 bits), 73 bytes captured (584 bits)
Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00)
Internet Protocol Version 4, Src: 172.16.15.99, Dst: 172.16.15.99
Transmission Control Protocol, Src Port: 4433, Dst Port: 55754, Seq: 1, Ack: 304, Len: 7
Transport Layer Security
    TLSv1.2 Record Layer: Alert (Level: Fatal, Description: Handshake Failure)
        Content Type: Alert (21)
        Version: TLS 1.2 (0x0303)
        Length: 2
        Alert Message
            Level: Fatal (2)
            Description: Handshake Failure (40)

Frame 7: 66 bytes on wire (528 bits), 66 bytes captured (528 bits)
Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00)
Internet Protocol Version 4, Src: 172.16.15.99, Dst: 172.16.15.99
Transmission Control Protocol, Src Port: 55754, Dst Port: 4433, Seq: 304, Ack: 8, Len: 0

Frame 8: 66 bytes on wire (528 bits), 66 bytes captured (528 bits)
Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00)
Internet Protocol Version 4, Src: 172.16.15.99, Dst: 172.16.15.99
Transmission Control Protocol, Src Port: 4433, Dst Port: 55754, Seq: 8, Ack: 304, Len: 0

Frame 9: 66 bytes on wire (528 bits), 66 bytes captured (528 bits)
Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00)
Internet Protocol Version 4, Src: 172.16.15.99, Dst: 172.16.15.99
Transmission Control Protocol, Src Port: 55754, Dst Port: 4433, Seq: 304, Ack: 9, Len: 0

Frame 10: 66 bytes on wire (528 bits), 66 bytes captured (528 bits)
Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00)
Internet Protocol Version 4, Src: 172.16.15.99, Dst: 172.16.15.99
Transmission Control Protocol, Src Port: 55754, Dst Port: 4433, Seq: 304, Ack: 9, Len: 0

Frame 11: 66 bytes on wire (528 bits), 66 bytes captured (528 bits)
Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00)
Internet Protocol Version 4, Src: 172.16.15.99, Dst: 172.16.15.99
Transmission Control Protocol, Src Port: 4433, Dst Port: 55754, Seq: 9, Ack: 305, Len: 0

BTW: tests were done on the master branch first (commit 26b7cc0).

@openssl-machine
Copy link

@openssl-machine openssl-machine commented Feb 26, 2020

Automated Ping: This issue is in a state where it requires action by @openssl/committers but the last update was 109 days ago

@vdukhovni
Copy link

@vdukhovni vdukhovni commented Feb 26, 2020

Ah, right. Yeah, I can't see a reason to do that either.

Making X509_VERIFY_PARAM transparently accept IP addresses anywhere it accepts hostnames is slightly non-trivial as there can be only one vpm->ip which must match, while there's a list of hostnames of which only one needs to match. I could change that but it's more intrusive. I think I'll just fix up SSL_set1_host() which is the newish API, while leaving X509_VERIFY_PARAM as it was.

So SSL_set1_host() will effectively just call X509_VERIFY_PARAM_set1_ip_asc() || X509_VERIFY_PARAM_set1_host() — i.e. if it works as an IP address, fine. Else it's a hostname.

While it is true that we support multiple hostnames, but only one IP address, this is not an issue for the set1 interface, because this always resets the list to just the given element. What would be harder to do is implement IP address support add1_host, but if you're not doing that, then set1_host could be polymorphic, while add1_host could be for names only...

The reason for multiple hostnames is partly DANE, partly prior art in Postfix where we can match either the domain or the MX host, ... Most applications only ever set one name, and send that as the SNI. So the case for multiple IPs (given no prior practice of accepting more than one at a time) is pretty weak. So I would not see lack of support for the add1 interface as an interface defect.

ssl/ssl_lib.c Outdated Show resolved Hide resolved
@vdukhovni
Copy link

@vdukhovni vdukhovni commented Jun 19, 2020

Looks better now. Is there anywhere in "apps", where we need to take care to not also use such hostnames as the implicit SNI, or is that already handled?

@openssl-machine
Copy link

@openssl-machine openssl-machine commented Jul 20, 2020

This PR is in a state where it requires action by @openssl/committers but the last update was 30 days ago

@vdukhovni vdukhovni dismissed bernd-edlinger’s stale review Jul 25, 2020

Issues addressed.

@vdukhovni
Copy link

@vdukhovni vdukhovni commented Jul 25, 2020

This should be ready to go, but needs a rebase to catch up with CHANGES.md that happened in the meantime. When pushing, please rebase CHANGES.md first.

@openssl-machine
Copy link

@openssl-machine openssl-machine commented Jul 26, 2020

This pull request is ready to merge

dwmw2 added 4 commits Oct 14, 2019
There is a slight mismatch here because X509_VERIFY_PARAM copes only
with a single IP address, and doesn't let it be cleared once it's set.
But this fixes up the major use case, making things easier for users to
get it right.

The sconnect demo now works for Legacy IP literals; for IPv6 it needs to
fix up the way it tries to split the host:port string, which will happen
in a subsequent patch.
Instead of naïvely trying to truncate at the first colon, use
BIO_get_conn_hostname(). That handles IPv6 literals correctly, even
stripping the [] from around them.
The X509_VERIFY_PARAM can only take a single IP address, although it can
have multiple hostnames. When SSL_add1_host() is given an IP address,
don't accept it if there is already one configured.
@mspncp mspncp force-pushed the dwmw2:ssl_add_ip branch to cc8b159 Jul 26, 2020
@mspncp
Copy link
Contributor

@mspncp mspncp commented Jul 26, 2020

Did the rebase to resolve the conflict in CHANGES.md and force-pushed the result. (This action does not require resetting the grace period IMHO.) Since I didn't review this pull request, I'll leave merging to @t8m or @vdukhovni.

openssl-machine pushed a commit that referenced this pull request Aug 3, 2020
There is a slight mismatch here because X509_VERIFY_PARAM copes only
with a single IP address, and doesn't let it be cleared once it's set.
But this fixes up the major use case, making things easier for users to
get it right.

The sconnect demo now works for Legacy IP literals; for IPv6 it needs to
fix up the way it tries to split the host:port string, which will happen
in a subsequent patch.

Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from #9201)
openssl-machine pushed a commit that referenced this pull request Aug 3, 2020
Instead of naïvely trying to truncate at the first colon, use
BIO_get_conn_hostname(). That handles IPv6 literals correctly, even
stripping the [] from around them.

Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from #9201)
openssl-machine pushed a commit that referenced this pull request Aug 3, 2020
The X509_VERIFY_PARAM can only take a single IP address, although it can
have multiple hostnames. When SSL_add1_host() is given an IP address,
don't accept it if there is already one configured.

Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from #9201)
openssl-machine pushed a commit that referenced this pull request Aug 3, 2020
…terals

Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from #9201)
@t8m
Copy link
Member

@t8m t8m commented Aug 3, 2020

Merged to master. Thank you for the PR and for the patience.

@t8m t8m closed this Aug 3, 2020
swenkeratmicrosoft pushed a commit to swenkeratmicrosoft/openssl that referenced this pull request Sep 1, 2020
There is a slight mismatch here because X509_VERIFY_PARAM copes only
with a single IP address, and doesn't let it be cleared once it's set.
But this fixes up the major use case, making things easier for users to
get it right.

The sconnect demo now works for Legacy IP literals; for IPv6 it needs to
fix up the way it tries to split the host:port string, which will happen
in a subsequent patch.

Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from openssl#9201)
swenkeratmicrosoft pushed a commit to swenkeratmicrosoft/openssl that referenced this pull request Sep 1, 2020
Instead of naïvely trying to truncate at the first colon, use
BIO_get_conn_hostname(). That handles IPv6 literals correctly, even
stripping the [] from around them.

Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from openssl#9201)
swenkeratmicrosoft pushed a commit to swenkeratmicrosoft/openssl that referenced this pull request Sep 1, 2020
The X509_VERIFY_PARAM can only take a single IP address, although it can
have multiple hostnames. When SSL_add1_host() is given an IP address,
don't accept it if there is already one configured.

Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from openssl#9201)
swenkeratmicrosoft pushed a commit to swenkeratmicrosoft/openssl that referenced this pull request Sep 1, 2020
…terals

Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
Reviewed-by: Tomas Mraz <tmraz@fedoraproject.org>
(Merged from openssl#9201)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

10 participants