GnuTLS TLS 1.2 handshake failure

[Robert Russo]

[ Impact ]
* GnuTLS fails to handshake using TLS 1.2 because of a protocol failure

[ Other info ]
I'm experiencing the same issue as here:

http://comments.gmane.org/gmane.network.gnutls.general/3713

I came across a SSL handshake problem with gnutls-cli when connecting to
some websites, see below. It is somehow specific to gnutls as
openssl/Chrome/Firefox can connect fine.

Is this is a bug in gnutls or do you have any ideas how to troubleshoot it?

$ gnutls-cli --version
gnutls-cli (GnuTLS) 2.12.23
Packaged by Debian (2.12.23-12ubuntu2.1)

[ Test case ]
$ gnutls-cli www.openlearning.com
Resolving 'www.openlearning.com'...
Connecting to '119.9.9.205:443'...
*** Fatal error: A TLS fatal alert has been received.
*** Received alert [40]: Handshake failed
*** Handshake has failed
GnuTLS error: A TLS fatal alert has been received.

$ gnutls-cli sequencewiz.com
Resolving 'sequencewiz.com'...
Connecting to '50.112.144.117:443'...
*** Fatal error: A TLS packet with unexpected length was received.
*** Handshake has failed
GnuTLS error: A TLS packet with unexpected length was received.

[ Regression potential ]
* low to moderate, this is an upstream commit dated back 6 years ago, that trusty sadly missed, but was manually tested to work and autopkgtests should give more confidence

Thank you,

Please back port the latest GnuTLS to Trusty as it is an LTS release and clearly GnuTLS 2.12 is an old branch.

I've also attached packet captures of this.

[Robert Russo (rrusso)]

Come on guys.

No one cares?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=767610

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Micah Gersten (micahg)]

This seems like a bug that should be fixed in the LTS rather than requesting a backport. The 3.2.11 version is available in trusty, but it's only community supported and doesn't have the utilities built since it's not the officially supported version. The version with 5 year support from Canonical is the old 2.12 version gnutls28 (3.2.11) has a lot of reverse dependencies, so a backport is non trivial. Let's see if the bug can be fixed in the older version.

[Robert Russo (rrusso)]

This would be IDEAL if it were fixed in the LTS.

[kenorb (kenorb)]

This bug breaks MetaTrader 4 installation process under wine (https://download.mql5.com/cdn/web/metaquotes.software.corp/mt4/mt4setup.exe).
This sounds like some regression, as older TLS authentication worked fine.

[js1 (sujiannming)]

Update to libgnutls26-2.12.23-12ubuntu2.5 broke ldapsearch and Apache Directory Studio for me in particular. Whatever the previous version was worked fine. Now, when trying to connect via TLS or SSL to our ldap server, I get the following with gnutls-cli:

# gnutls-cli --print-cert -p 636 192.168.125.187
Connecting to '192.168.125.187:636'...
*** Fatal error: A TLS packet with unexpected length was received.
*** Handshake has failed
GnuTLS error: A TLS packet with unexpected length was received.

But, works fine with openssl:

# openssl s_client -connect 192.168.125.187:636 -CApath /etc/ssl/certs/
CONNECTED(00000003)
depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
verify return:1
depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
verify return:1
depth=1 C = US, ST = MI, L = Ann Arbor, O = Internet2, OU = InCommon, CN = InCommon RSA Server CA
verify return:1
depth=0 C = US, postalCode = MyZip, ST = GA, L = MyTown, street = MyStreetAddress, O = MyOrg, CN = 192.168.125.187
verify return:1
---
Certificate chain
 0 s:/C=US/postalCode=MyZip/ST=MyState/L=MyTown/street=MyStreetAddress/O=MyOrg/CN=192.168.125.187
   i:/C=US/ST=MI/L=Ann Arbor/O=Internet2/OU=InCommon/CN=InCommon RSA Server CA
 1 s:/C=US/ST=MI/L=Ann Arbor/O=Internet2/OU=InCommon/CN=InCommon RSA Server CA
   i:/C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority
 2 s:/C=US/ST=New Jersey/L=Jersey City/O=The USERTRUST Network/CN=USERTrust RSA Certification Authority
   i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIHIDCCBgigAwIBAgIQeJi0ZL9m+H676krkb1nDDDANBgkqhkiG9w0BAQsFADB2
MQswCQYDVQQGEwJVUzELMAkGA1UECBMCTUkxEjAQBgNVBAcTCUFubiBBcmJvcjES
MBAGA1UEChMJSW50ZXJuZXQyMREwDwYDVQQLEwhJbkNvbW1vbjEfMB0GA1UEAxMW
SW5Db21tb24gUlNBIFNlcnZlciBDQTAeFw0xNTAyMDMwMDAwMDBaFw0xODAyMDIy
MzU5NTlaMIGaMQswCQYDVQQGEwJVUzEOMAwGA1UEERMFMzAzMjIxCzAJBgNVBAgT
AkdBMRAwDgYDVQQHEwdBdGxhbnRhMR0wGwYDVQQJExQxNzg0IE4gRGVjYXR1ciBS
ZCBORTEZMBcGA1UEChMQRW1vcnkgVW5pdmVyc2l0eTEiMCAGA1UEAxMZbGRzYXV0
aC5zZXJ2aWNlLmVtb3J5LmVkdTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBAM1fBQTBn8MuVC07NkkR5nvQppHUOk7l8KOu0MFCnyTaQFE0lOC7k4cGcsHS
0LmKFPwDaMUsGs23ER5+TfBa9JRLfKVbgvF7Uqt3X9CwGnTJvLjest59mWd4oGZm
vKBPcV3WwkAGgC2UJKUcYrQXLp5yTAjlBhgmoz5ZKa2fIRS1jPWDI5Pn9yzssw5j
OIwuoHo68jocpz8sSIN3gQ6gIM+5rIs1rgJ/SVS40sRrtBAneP3Qnr6MF3DQrSYP
8TbkCAEjf4xYqVa5f3Oy8NdC2v4Jk7VVTDoiNDpEzFbLzoCI0NpYvZKWPx3l3xr/
jZoYM+Mi+rviCqW8M88KpxBoTf0CAwEAAaOCA4MwggN/MB8GA1UdIwQYMBaAFB4F
o3ePbJbiW4dLprSGrHEADOc4MB0GA1UdDgQWBBSJE3N+JO9Yhb3bxPnUC90OhJy0
xjAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAdBgNVHSUEFjAUBggrBgEF
BQcDAQYIKwYBBQUHAwIwZwYDVR0gBGAwXjBSBgwrBgEEAa4jAQQDAQEwQjBABggr
BgEFBQcCARY0aHR0cHM6Ly93d3cuaW5jb21tb24ub3JnL2NlcnQvcmVwb3NpdG9y
eS9jcHNfc3NsLnBkZjAIBgZngQwBAgIwRAYDVR0fBD0wOzA5oDegNYYzaHR0cDov
L2NybC5pbmNvbW1vbi1yc2Eub3JnL0luQ29tbW9uUlNBU2VydmVyQ0EuY3JsMHUG
CCsGAQUFBwEBBGkwZzA+BggrBgEFBQcwAoYyaHR0cDovL2NydC51c2VydHJ1c3Qu
Y29tL0luQ29tbW9uUlNBU2VydmVyQ0FfMi5jcnQwJQYIKwYBBQUHMAGGGWh0dHA6
Ly9vY3NwLnVzZXJ0cnVzdC...

[js1 (sujiannming)]

FWIW, our ldapserver uses the following, which gnutls26 does not support but gnutls30 in wily does:

- Status: The certificate is trusted.
- Successfully sent 0 certificate(s) to server.
- Description: (TLS1.2)-(ECDHE-RSA-SECP256R1)-(AES-256-CBC)-(SHA384)
- Session ID: 8C:43:00:00:5D:F2:98:2F:60:C7:A1:3A:C4:DA:D3:2D:A3:76:8F:6D:83:AE:AA:D6:6C:E3:90:E4:10:91:C0:AD
- Ephemeral EC Diffie-Hellman parameters
 - Using curve: SECP256R1
 - Curve size: 256 bits
- Version: TLS1.2
- Key Exchange: ECDHE-RSA
- Server Signature: RSA-SHA1
- Cipher: AES-256-CBC
- MAC: SHA384
- Compression: NULL
- Handshake was completed

[Marc Deslauriers (mdeslaur)]

It looks like the servers listed in the bug description require SIGN-RSA-SHA384, which gnutls26 doesn't support.

The issue can be reproduced with gnutls28 by disabling the additional signature algorithms:

gnutls-cli --priority "NORMAL:-SIGN-ECDSA-SHA256:-SIGN-RSA-SHA384:-SIGN-ECDSA-SHA384:-SIGN-RSA-SHA512:-SIGN-ECDSA-SHA512:-SIGN-RSA-SHA224:-SIGN-DSA-SHA224:-SIGN-ECDSA-SHA224:-SIGN-ECDSA-SHA1" -d 256 sequencewiz.com

Fixing this likely requires at least the following commit to be backported:

https://gitlab.com/gnutls/gnutls/commit/75b493132239e824d671f4b09d1dfd0f7ca6a8b1

[Samuel Leslie (sdl)]

We encountered this bug today and it has the potential to be pretty nasty if you're unfortunate enough to hit it. In our case we have several systems which perform authentication against a Windows domain using LDAPS. We recently updated the TLS certificate on those systems and all the services which perform LDAPS authentication starting failing with the symptoms described earlier in this bug.

The new TLS certificate we installed had the same key size and hash algorithm, but it turned out the root CA & intermediate certificate were using SHA384 as the signature hash. This in turn caused the LDAPS connections to stop working. Given the CA's certificates were using SHA384 reissuing the certificate wasn't going to help and downgrading the TLS version was not at all desirable given the potential security implications.

I've backported the commit referenced by Marc and confirmed it resolves the problem for us. In my view it'd be wise to push this out to 14.04 users as this issue is going to presumably become more prominent as more certificates start using stronger hash algorithms and TLS 1.2 becomes more prevalent.

[Seth Arnold (seth-arnold)]

Hello Samuel, thanks for doing this investigation. This feels like a reasonable change to address through a Stable Release Update; the process is a bit involved, but largely so we're sure we don't break existing users in the process.

Are you in a position where you can prepare a debdiff? There's some guidelines on https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation (it's not a perfect match since that page is for security updates, not SRUs, but it's hopefully helpful.)

See also https://wiki.ubuntu.com/StableReleaseUpdates

Thanks

[Samuel Leslie (sdl)]

Hi Seth,

I've attached a debdiff which is generated off the latest gnutls26 package: 2.12.23-12ubuntu2.7. That said, no changes to my earlier patch were required to apply cleanly. Hopefully this is what you're after?

I should also add that this patch should ideally be reviewed by someone knowledgeable about GnuTLS and C, as I don't consider myself to meet either of those requirements! Particularly given this is a security library.

Cheers,
-SDL

[Samuel Leslie (sdl)]

Just wanted to check if there's anything else I can do to assist with this being pushed out as an update? We're pretty eager to have this incorporated as until it is, any updates to GnuTLS need to have the attached patch manually backported by us to avoid breakage on various services we run with affected certificate chains!

[Michael (shotoflove)]

I'm also having the same issue as Samuel.

[Michael (shotoflove)]

Where can I download this patch? The link doesn't work for me, thanks.

[Samuel Leslie (sdl)]

Links to .diff & .debdiff files work fine for me? Tested in Chrome's Incognito mode not logged into the site. I'll email you the patches directly regardless.

[Samuel Leslie (sdl)]

Anything we can do to get some activity on this bug? The patch is done to my knowledge and just needs to be reviewed. Am mindful that this is going to continue to break for afflicted users as gnutls is periodically updated.

[Samuel Leslie (sdl)]

Somewhat ironically, an update for libgnutls26 was released the same day I made my last comment, which I wasn't aware of at the time. This has broken libgnutls26 on affected systems once again. I confirm the attached patch still applies cleanly with the latest sources.

[Simon Quigley (tsimonq2)]

Hello Samuel, apologies for a delay on the review. Here's a couple of things I suggest you do with the patch before it is uploaded:
 1. Please run dch -r and make sure that UNRELEASED now states trusty.
 2. In the changelog, please begin all lines with text with a bullet point or sub-bullet point. I would suggest changing the changelog to the following (also contains some wording changes):
  * Backport an upstream commit for better TLS 1.2 compatibility during handshakes (LP: #1444656):
    - https://gitlab.com/gnutls/gnutls/commit/75b493132239e824d671f4b09d1dfd0f7ca6a8b1
    - This fixes a handshake failure on TLS 1.2 connections when one or more
      certificates in the chain use the SHA384 or SHA512 signature algorithm.
 3. Please add a DEP-3 header. You can do that by running `quilt header --dep3 -e`. More details are available here: http://dep.debian.net/deps/dep3/ .

Once those packaging changes are done, I will be happy to look more at the content of the patch (but in my opinion that's a separate topic, because packaging the backport is different than checking the validity of the backport). As such, I'm unsubscribing ~ubuntu-sponsors. Please feel free to resubscribe ~ubuntu-sponsors once you have an updated patch, and I will promptly review your patch and upload if it looks good.

Thank you for your contribution to Ubuntu and your help in getting this bug fixed!

[Samuel Leslie (sdl)]

Thanks for the feedback Simon. I've uploaded a new debdiff which hopefully correctly incorporates all of your suggested changes. I'll resubscribe ~ubuntu-sponsors to hopefully get this merged. Thanks again.

[Gianfranco Costamagna (costamagnagianfranco)]

ok looks good to me, uploaded.

[Gianfranco Costamagna (costamagnagianfranco)]

I had to do some little changes in changelog and patch
(you are not the author for the code change, it is upstream)

[Gianfranco Costamagna (costamagnagianfranco)]

Please test gnutls26 that will be available in my ppa in a few minutes
https://launchpad.net/~costamagnagianfranco/+archive/ubuntu/locutusofborg-ppa

[Samuel Leslie (sdl)]

Excellent thanks, I'll test the PPA tonight (after-hours our time). Apologies for the author issue, I wasn't sure if it should reflect the upstream author or the person who submitted the patch.

[Samuel Leslie (sdl)]

Can't see the package in your PPA. Something may have gone wrong?

[Gianfranco Costamagna (costamagnagianfranco)]

Hello
>Apologies for the author issue, I wasn't sure if it should reflect the upstream author or the person who submitted the patch.

I'm not even sure either :) usually the author of the packaging changes is reflected in debian/changelog, this is why I removed it from the patch

>Can't see the package in your PPA. Something may have gone wrong?

Reuploaded, I did remove it by error in my daily ppa cleanup :P

it is called build1 now, because of same versioning can't be reuploaded in the same ppa

[Andy Whitcroft (apw)]

It appears that this upload was based on the fix in -proposed for bug #1709193, but that has failed verification and has an updated version in that bug. These two need to be remerged and re-uploaded.

[Andy Whitcroft (apw)]

An upload of gnutls26 to trusty-proposed has been rejected from the upload queue for the following reason: "This update is based on a version in -proposed which has since failed verification. See Bug: #1709193.".

[Gianfranco Costamagna (costamagnagianfranco)]

I reuploaded the same package with the followup fix for #1709193

thanks!

[Gianfranco Costamagna (costamagnagianfranco)]

ppa:costamagnagianfranco/costamagnagianfranco-ppa <-- please test

[Samuel Leslie (sdl)]

Unless I'm going mad it's still not present in your PPA? Can you upload the updated debdiff which incorporates the follow-up fix for #1709193 and I can just compile and test locally if necessary?

[Gianfranco Costamagna (costamagnagianfranco)]

We are waiting for security team for this bug...
Please hold on and ping back in one week if nothing changes

[Robie Basak (racb)]

Driving through with my SRU hat.

Regression Potential of "None" or "Low" is unacceptable. Please review https://wiki.ubuntu.com/StableReleaseUpdates#Procedure.

How will you test that this doesn't impact protocol negotiation unrelated to this bug (ie. unaffected users)?

Since this is particularly security sensitive code, has anyone knowledgeable in the area reviewed the patch in the specific context of this backport, or is this just a blind cherry-pick?

Are you pushing this through the SRU or security process? I'm reviewing it from the SRU queue, but comments here and the bug subscriptions suggest that security is involved?

[Samuel Leslie (sdl)]

Robie:
- Agree the regression potential is likely moderate given the nature of the change. That said, the change is implemented already in newer Ubuntu releases via inclusion of newer GnuTLS releases, which may provide some degree of confidence in the correctness of the fix.
- Unclear how best to test that regressions aren't introduced. Does GnuTLS have an existing appropriate test suite which can be leveraged? I can say we've been running a patched build of GnuTLS per earlier attachment on our servers without issue, but that's obviously not sufficient for any sort of sign-off.
- Very strongly agree that this patch needs to be reviewed by someone suitably knowledgeable about GnuTLS internals and the relevant security topics. The included patch is just a cherry-pick of the relevant commit which fixes the issue upstream.
- The patch does not fix a security issue, but does fix a bug in security sensitive code. In that respect, bugs in the patch could obviously very easily introduce security issues, so careful review is required.

All of the above said, I'm not sure I can contribute much more than I already have. The issue is identified, I've backported the relevant commit, and can confirm it works based on my own testing and internal deployment at my workplace. What's needed now is review of the fix and potentially more testing.

[Marc Deslauriers (mdeslaur)]

I have reviewed the debdiff in comment #24. I validated that is indeed a reasonable backport of the commit that was identified in comment #9.

I have successfully tested it with our usual security team test scripts.

While it may be possible for the backport to introduce a bug, I can't see anything that particularly stands out as being problematic and I believe we should go ahead with this SRU.

ACK from the security team.

[Marc Deslauriers (mdeslaur)]

I have re-uploaded the package for processing by the SRU team with a slight changelog formatting change. Thanks.

[Terje Rafelsen (terjer)]

When will this be assigned and patched to 14.04?

Have several systems affected that needs a patch.

[Seth Arnold (seth-arnold)]

If I'm reading the "update excuses" output correctly, this package update is blocked by autopkgtest failures:

[...]
ok 14 /tls/connection/simultaneous-sync
**
GLib-Net:ERROR:connection.c:368:run_echo_server: assertion failed (error == NULL): Error performing TLS handshake: The specified session has been invalidated for some reason. (g-tls-error-quark, 1)
# GLib-Net:ERROR:connection.c:368:run_echo_server: assertion failed (error == NULL): Error performing TLS handshake: The specified session has been invalidated for some reason. (g-tls-error-quark, 1)
Test glib-networking/connection.test failed: Child process killed by signal 6
Running test: /usr/share/installed-tests/glib-networking/file-database.test
[...]

That's from https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-trusty/trusty/ppc64el/g/glib-networking/20170818_000323_c2d95@/log.gz

It looks like none of the architectures for glib-networking succeeded:

http://people.canonical.com/~ubuntu-archive/proposed-migration/trusty/update_excuses.html#gnutls26

Since the failures are specifically about TLS handshake failures, it feels unlikely to be transient test failures. Someone needs to investigate this further.

Thanks

[Timo Aaltonen (tjaalton)]

I think the autopkgtest failures mentioned on #40 were actually from 2.12.23-12ubuntu2.9 which was later removed from the archive (bug 1709193)

-12ubuntu2.10 has been sitting on the queue for well over a year now, so I'll release it because it was manually tested to be fine (#37) and then we'll see if autopkgtests still fail with the new backport or not

[Timo Aaltonen (tjaalton)]

Hello Robert, or anyone else affected,

Accepted gnutls26 into trusty-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/gnutls26/2.12.23-12ubuntu2.10 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested and change the tag from verification-needed-trusty to verification-done-trusty. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed-trusty. In either case, without details of your testing we will not be able to proceed.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping!

N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days.

[Gianfranco Costamagna (costamagnagianfranco)]

I like it
dpkg -l |grep gnutls
ii gnutls-bin 3.0.11+really2.12.23-12ubuntu2.10 amd64 GNU TLS library - commandline utilities
ii libgnutls26:amd64 2.12.23-12ubuntu2.10 amd64 GNU TLS library - runtime library

# gnutls-cli www.openlearning.com
Resolving 'www.openlearning.com'...
Connecting to '52.187.244.227:443'...
- Ephemeral Diffie-Hellman parameters
 - Using prime: 1024 bits
 - Secret key: 1021 bits
 - Peer's public key: 1024 bits
- Certificate type: X.509
 - Got a certificate list of 3 certificates.
 - Certificate[0] info:
  - subject `OU=Domain Control Validated,OU=PositiveSSL Wildcard,CN=*.openlearning.com', issuer `C=GB,ST=Greater Manchester,L=Salford,O=COMODO CA Limited,CN=COMODO RSA Domain Validation Secure Server CA', RSA key 2048 bits, signed using RSA-SHA256, activated `2016-06-22 00:00:00 UTC', expires `2019-07-08 23:59:59 UTC', SHA-1 fingerprint `1a82ffae6c13a1beb04cf67c0397300cdb4f45af'
 - Certificate[1] info:
  - subject `C=GB,ST=Greater Manchester,L=Salford,O=COMODO CA Limited,CN=COMODO RSA Domain Validation Secure Server CA', issuer `C=GB,ST=Greater Manchester,L=Salford,O=COMODO CA Limited,CN=COMODO RSA Certification Authority', RSA key 2048 bits, signed using RSA-SHA384, activated `2014-02-12 00:00:00 UTC', expires `2029-02-11 23:59:59 UTC', SHA-1 fingerprint `339cdd57cfd5b141169b615ff31428782d1da639'
 - Certificate[2] info:
  - subject `C=GB,ST=Greater Manchester,L=Salford,O=COMODO CA Limited,CN=COMODO RSA Certification Authority', issuer `C=SE,O=AddTrust AB,OU=AddTrust External TTP Network,CN=AddTrust External CA Root', RSA key 4096 bits, signed using RSA-SHA384, activated `2000-05-30 10:48:38 UTC', expires `2020-05-30 10:48:38 UTC', SHA-1 fingerprint `f5ad0bcc1ad56cd150725b1c866c30ad92ef21b0'
- The hostname in the certificate matches 'www.openlearning.com'.
- Peer's certificate issuer is unknown
- Peer's certificate is NOT trusted
- Version: TLS1.2
- Key Exchange: DHE-RSA
- Cipher: AES-256-CBC
- MAC: SHA1
- Compression: NULL
- Handshake was completed

- Simple Client Mode:

^C
# gnutls-cli sequencewiz.com
Resolving 'sequencewiz.com'...
Connecting to '50.112.50.214:443'...
- Ephemeral Diffie-Hellman parameters
 - Using prime: 1024 bits
 - Secret key: 1020 bits
 - Peer's public key: 1022 bits
- Certificate type: X.509
 - Got a certificate list of 2 certificates.
 - Certificate[0] info:
  - subject `CN=sequencewiz.com', issuer `C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3', RSA key 2048 bits, signed using RSA-SHA256, activated `2019-03-09 16:31:42 UTC', expires `2019-06-07 16:31:42 UTC', SHA-1 fingerprint `0c6d85565ccc8a9f1d9b0bceb1f1827d884b6122'
 - Certificate[1] info:
  - subject `C=US,O=Let's Encrypt,CN=Let's Encrypt Authority X3', issuer `O=Digital Signature Trust Co.,CN=DST Root CA X3', RSA key 2048 bits, signed using RSA-SHA256, activated `2016-03-17 16:40:46 UTC', expires `2021-03-17 16:40:46 UTC', SHA-1 fingerprint `e6a3b45b062d509b3382282d196efe97d5956ccb'
- The hostname in the certificate matches 'sequencewiz.com'.
- Peer's certificate issuer is unknown
- Peer's certificate is NOT trusted
- Version: TLS1.2
- Key Exchange: DHE-RSA
- Cipher: AES-...