Check TLS certificates with IPv6 addresses #52

HLFH · 2020-04-11T12:07:50Z

As acme-ip is not yet implemented into boulder, I generate TLS certificates for IP addresses with minica that facilitates issuance of self-signed certificates.

So I do:

docker run my_image_id https my_ipv6_address

And I get:

Supported methods
Address not available - connect(2) for [my_ipv6_address]:443

Do you plan to support the TLS certificates with IPv6 addresses check in the future?
I see it works for IPv4 addresses like 1.1.1.1: https://cryptcheck.fr/https/1.1.1.1

Thanks,
HLFH

The text was updated successfully, but these errors were encountered:

aeris · 2020-04-11T12:43:05Z

It already support IPv6:

$ docker run --rm aeris22/cryptcheck https 2001:bc8:1200:4:208:a2ff:fe0c:67ea   
2001:bc8:1200:4:208:a2ff:fe0c:67ea:443

Supported methods
  Method TLSv1_2

Supported ciphers
  Cipher TLSv1_2 ECDHE-ECDSA-AES128-GCM-SHA256 [aead]
    PFS : ECC 256 bits
  Cipher TLSv1_2 ECDHE-ECDSA-AES256-GCM-SHA384 [aead]
    PFS : ECC 256 bits
  Cipher TLSv1_2 ECDHE-ECDSA-CHACHA20-POLY1305 [aead]
    PFS : ECC 256 bits
  Cipher TLSv1_2 ECDHE-ECDSA-AES128-SHA256 []
    PFS : ECC 256 bits
  Cipher TLSv1_2 ECDHE-ECDSA-AES256-SHA384 []
    PFS : ECC 256 bits

But you need to have working IPv6 stack on the host performing check and to activate IPv6 on docker daemon:

# cat /etc/docker/daemon.json 
{
  "ipv6": true,
  "fixed-cidr-v6": "xxxx:xxxx:xxxx::/80"
}

Currently web frontend is not "IPv6 ready" because of confusion about :, guessed as port separator, on naked IPv6. But fully dual-stacked hostname is checked for both IPv4 & IPv6, as on https://cryptcheck.fr/https/imirhil.fr

HLFH · 2020-04-13T11:58:58Z

@aeris

As stated in the Docker documentation:

IPv6 networking is only supported on Docker daemons running on Linux hosts.
Docker for Mac does not support IPv6 networking.

So I migrated Docker from Mac platform to ArchLinux and I followed your advice for /etc/docker/daemon.json:

{
  "ipv6": true,
  "fixed-cidr-v6": "xxxx:xxxx:xxxx:xxxx::/56"
}

And it worked in CLI.

Regarding the web frontend, I would presume the confusion can be fixed with the fact that RFC 3986, section 3.2.2 clarifies that:

A host identified by an Internet Protocol literal address, version 6
[RFC3513] or later, is distinguished by enclosing the IP literal
within square brackets ("[" and "]"). This is the only place where
square bracket characters are allowed in the URI syntax. In
anticipation of future, as-yet-undefined IP literal address formats,
an implementation may use an optional version flag to indicate such a
format explicitly rather than rely on heuristic determination.

The Cloudflare DNS service is accessible in IPv6 on:

https://[2606:4700:4700::1111]/
https://[2606:4700:4700::1001]/

If we use in CLI the https command to check TLS certificates with IPv6 addresses, the HSTS check should not be done as RFC 6797 Appendix A excludes IP addresses:

HSTS Hosts are identified only via domain names -- explicit IP
address identification of all forms is excluded.

aeris · 2020-04-13T12:46:33Z

If we use in CLI the https command to check TLS certificates with IPv6 addresses, the HSTS check should not be done as RFC 6797 Appendix A excludes IP addresses:

HSTS Hosts are identified only via domain names -- explicit IP
address identification of all forms is excluded.

I assume https command is used with a FQDN and not an IP, because of the trouble of vhost only testable with a valid FQDN (or you catch the default vhost which is neither reproducible nor guessable nor stable). And by design CryptCheck always validates both endpoint for dual-IP-stacked endpoint, testing naked IP is not very usefull, standard users don't use such address.
The only check where nake address seems acceptable is the tls command (basically this is already HTTPS = TLS + HSTS).

But I will try to disable HSTS on naked IP address to be compliant with the RFC.

HLFH · 2020-04-13T15:05:45Z

I presume the Docker build is using ruby 2.3.8.

I want to check the TLS certificate of Cloudflare at URI [2606:4700:4700::1111]:443.

docker run --rm aeris22/cryptcheck tls 2606:4700:4700::1111 443

I am getting:

docker run --rm aeris22/cryptcheck tls 2606:4700:4700::1111 443
2606:4700:4700::1111:443

Supported methods
  Method TLSv1_2
  Method TLSv1_1
  Method TLSv1

Supported ciphers
  Cipher TLSv1_2 ECDHE-ECDSA-AES128-GCM-SHA256 [aead]
    PFS : ECC 256 bits
  Cipher TLSv1_2 ECDHE-ECDSA-AES256-GCM-SHA384 [aead]
    PFS : ECC 256 bits
  Cipher TLSv1_2 ECDHE-ECDSA-CHACHA20-POLY1305 [aead]
    PFS : ECC 256 bits
  Cipher TLSv1_2 ECDHE-ECDSA-CHACHA20-POLY1305-D [aead]
    PFS : ECC 256 bits
  Cipher TLSv1_2 ECDHE-ECDSA-AES128-SHA256 []
    PFS : ECC 256 bits
  Cipher TLSv1_2 ECDHE-ECDSA-AES256-SHA384 []
    PFS : ECC 256 bits
  Cipher TLSv1_2 ECDHE-ECDSA-AES128-SHA [sha1]
    PFS : ECC 256 bits
  Cipher TLSv1_2 ECDHE-ECDSA-AES256-SHA [sha1]
    PFS : ECC 256 bits
  Cipher TLSv1_1 ECDHE-ECDSA-AES128-SHA [sha1]
    PFS : ECC 256 bits
  Cipher TLSv1_1 ECDHE-ECDSA-AES256-SHA [sha1]
    PFS : ECC 256 bits
  Cipher TLSv1 ECDHE-ECDSA-AES128-SHA [sha1]
    PFS : ECC 256 bits
  Cipher TLSv1 ECDHE-ECDSA-AES256-SHA [sha1]
    PFS : ECC 256 bits

Cipher suite preferences
  TLSv1_2  : ECDHE-ECDSA-AES128-GCM-SHA256, ECDHE-ECDSA-CHACHA20-POLY1305, ECDHE-ECDSA-CHACHA20-POLY1305-D, ECDHE-ECDSA-AES128-SHA, ECDHE-ECDSA-AES128-SHA256, ECDHE-ECDSA-AES256-GCM-SHA384, ECDHE-ECDSA-AES256-SHA, ECDHE-ECDSA-AES256-SHA384
  TLSv1_1  : ECDHE-ECDSA-AES128-SHA, ECDHE-ECDSA-AES256-SHA
  TLSv1  : ECDHE-ECDSA-AES128-SHA, ECDHE-ECDSA-AES256-SHA

Supported elliptic curves
  ECC curve secp256k1
  ECC curve prime256v1
Curves preference : prime256v1, secp256k1

Fallback SCSV : not supported

Certificates
  Certificate /C=US/ST=California/L=San Francisco/O=Cloudflare, Inc./CN=cloudflare-dns.com [2393062632280249844899714234728687389] issued by /C=US/O=DigiCert Inc/CN=DigiCert ECC Secure Server CA
    Key : ECC prime256v1 256 bits
    Identity : invalid
    Trust : trusted

Grade : V
{
    :critical => {
        :mdc2_sign => false,
         :md2_sign => false,
         :md4_sign => false,
         :md5_sign => false,
         :sha_sign => false,
        :sha1_sign => false,
              :ecc => false,
            :sslv2 => false,
            :sslv3 => false,
              :dss => false,
        :anonymous => false,
             :null => false,
           :export => false,
              :des => false,
              :md5 => false,
              :rc4 => false,
          :sweet32 => false
    },
       :error => {
            :ecc => false,
        :tlsv1_0 => true,
        :tlsv1_1 => true,
            :pfs => false
    },
     :warning => {
         :ecc => false,
        :sha1 => true,
         :dhe => false
    },
        :good => {
        :fallback_scsv => false,
                 :aead => true
    },
       :great => {},
        :best => {}
}

I wonder why the Identity is invalid.
I presume the file cert.rb is being called on this very specific function:

::OpenSSL::SSL.verify_certificate_identity @cert, host

Does that mean with the current Docker build, it is returning false to show in the CLI the Identity is invalid?

When I am using ruby 2.7.1 to try this function on the same host:

openssl s_client -showcerts -connect [2606:4700:4700::1111]:443 </dev/null 2>/dev/null|openssl x509 -outform PEM >cert.pem

I am getting:

irb

require 'openssl'
raw = File.read "cert.pem"
cert = OpenSSL::X509::Certificate.new raw
::OpenSSL::SSL.verify_certificate_identity cert, '2606:4700:4700::1111'
=> true #and not false

For this latter test, the openssl version is OpenSSL 1.1.1f.
For the related 1.1.1.1 URI with the aeris22/cryptcheck Docker build, I am getting the Identity as "valid", so it seems there is a bug here when we do the check for the IPv6 addresses.

aeris · 2020-04-13T17:22:32Z

There is a bug in Ruby OpenSSL v2.1.2 binding. Comparison is done with string without any normalization before comparison.
2606:4700:4700::1111 is so basically compared to 2606:4700:4700:0:0:0:0:1111 which is false…
It was corrected on master but not released at the moment.

HLFH · 2020-04-14T09:30:29Z

I quote you:

I'm currently working on a huge rework to try supporting TLSv1.3 with a dual stacked Ruby (2.3 & 2.6).

Yusuke Endoh from the ruby team has just said:

Ruby 2.7 bundles an unreleased version 2.2.0 of openssl that includes the PR.
The version management of gems bundled with Ruby by default are not well-organised.

Happily, your huge rework (unless it is cryptcheck-engine project without the openssl dep?),
with Ruby 2.6 included will solve this bug as Ruby bundles the unreleased version 2.2.0 of openssl from ruby 2.6.0 preview 3 onwards.

aeris · 2020-04-14T09:45:31Z

It's not related to the full rewrite of openssl dep 😂
I just try to be able to run checking code on 2.6, to be able to access TLSv1.3 too.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Check TLS certificates with IPv6 addresses #52

Check TLS certificates with IPv6 addresses #52

HLFH commented Apr 11, 2020 •

edited

Loading

aeris commented Apr 11, 2020 •

edited

Loading

HLFH commented Apr 13, 2020 •

edited

Loading

aeris commented Apr 13, 2020

HLFH commented Apr 13, 2020 •

edited

Loading

aeris commented Apr 13, 2020

HLFH commented Apr 14, 2020 •

edited

Loading

aeris commented Apr 14, 2020

Check TLS certificates with IPv6 addresses #52

Check TLS certificates with IPv6 addresses #52

Comments

HLFH commented Apr 11, 2020 • edited Loading

aeris commented Apr 11, 2020 • edited Loading

HLFH commented Apr 13, 2020 • edited Loading

aeris commented Apr 13, 2020

HLFH commented Apr 13, 2020 • edited Loading

aeris commented Apr 13, 2020

HLFH commented Apr 14, 2020 • edited Loading

aeris commented Apr 14, 2020

HLFH commented Apr 11, 2020 •

edited

Loading

aeris commented Apr 11, 2020 •

edited

Loading

HLFH commented Apr 13, 2020 •

edited

Loading

HLFH commented Apr 13, 2020 •

edited

Loading

HLFH commented Apr 14, 2020 •

edited

Loading