Register a SA Forums Account here!
JOINING THE SA FORUMS WILL REMOVE THIS BIG AD, THE ANNOYING UNDERLINED ADS, AND STUPID INTERSTITIAL ADS!!!

You can: log in, read the tech support FAQ, or request your lost password. This dumb message (and those ads) will appear on every screen until you register! Get rid of this crap by registering your own SA Forums Account and joining roughly 150,000 Goons, for the one-time price of $9.95! We charge money because it costs us money per month for bills, and since we don't believe in showing ads to our users, we try to make the money back through forum registrations.
 
  • Locked thread
maskenfreiheit
Dec 30, 2004
So I installed wget using brew, because wget is useful.

However, recently I've noticed many sites that use HTTPS freak it out:



code:
$ wget [url]https://dl.google.com/dl/android/aosp/razor-mob30x-factory-52684dff.zip[/url]
--2017-07-02 11:13:50--  [url]https://dl.google.com/dl/android/aosp/razor-mob30x-factory-52684dff.zip[/url]
Resolving dl.google.com (dl.google.com)... 172.217.1.46, 2607:f8b0:4009:802::200e
Connecting to dl.google.com (dl.google.com)|172.217.1.46|:443... connected.
ERROR: The certificate of ‘dl.google.com’ is not trusted.
ERROR: The certificate of ‘dl.google.com’ hasn't got a known issuer.
But when I check out Google's site, the connection seems fine:





Is there something nefarious going on here, or is this benign and I need to find some sort of warning override flag?

Adbot
ADBOT LOVES YOU

telcoM
Mar 21, 2009
Fallen Rib

maskenfreiheit posted:

So I installed wget using brew, because wget is useful.

However, recently I've noticed many sites that use HTTPS freak it out:

Is there something nefarious going on here, or is this benign and I need to find some sort of warning override flag?

wget requires a version of openssl as a dependency, and it looks like your openssl might have a bit stale set of root certificates for various Certification Authorities.
Because of this, wget+openssl cannot verify Google's certificate as legitimate, and will output an error message.

Run:
code:
brew info openssl
and you will get the version of your current brew-installed openssl used by your brew-installed software, and a list of openssl versions available through the brew system, and various other stuff. If the version older than 1.0.2l at the moment, it's time to run "brew upgrade openssl". Then try wget again: your problem may now be gone.

maskenfreiheit
Dec 30, 2004
Thanks!

openssl is up to date and I still get errors though

¯\_(ツ)_/¯

telcoM
Mar 21, 2009
Fallen Rib

maskenfreiheit posted:

Thanks!

openssl is up to date and I still get errors though

¯\_(ツ)_/¯

From your original posted output, I can see the actual destination IP addresses: 172.217.1.46 and the IPv6 2607:f8b0:4009:802::200e.

Wait.

From developers.google.com, you get a *.google.com certificate that is issued by "Google Internet Authority G2". That's the same thing I'm seeing.

But from dl.google.com, you are getting another certificate that is specific to dl.google.com, and I'm not getting that even though I'm trying the same destination IP address as you. Either someone at Google has made an oops, or there is something more fishy going on.

Let's dig deeper.

This command will get as much information on the SSL/TLS connection as possible:
code:
openssl s_client -showcerts -tlsextdebug -bugs -status -connect 172.217.1.46:443 </dev/null > ~/Desktop/ssl-diag.txt
(Of course, you can replace the "172.217.1.46:443" part with the IP address and port number of any https server you wish to check SSL/TLS details on.)

It will output something like this, which indicates how far OpenSSL got in verifying the chain of server and CA certificates:
code:
depth=2 /C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
verify error:num=20:unable to get local issuer certificate
verify return:0
DONE
And it will also produce a text file "ssl-diag.txt" on your desktop, which will contain something like this:
code:
CONNECTED(00000003)
TLS server extension "renegotiate" (id=65281), len=1
0001 - <SPACES/NULS>
TLS server extension "server ticket" (id=35), len=0
OCSP response: no response sent
---
Certificate chain
 0 s:/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com
   i:/C=US/O=Google Inc/CN=Google Internet Authority G2
-----BEGIN CERTIFICATE-----
MIIISDCCBzCgAwIBAgIIJnmzNpQlObIwDQYJKoZIhvcNAQELBQAwSTELMAkGA1UE
<<many lines of alphabet soup = a PEM encoded public part of a certificate>>
-----END CERTIFICATE-----
 1 s:/C=US/O=Google Inc/CN=Google Internet Authority G2
   i:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
-----BEGIN CERTIFICATE-----
<<more alphabet soup>>
-----END CERTIFICATE-----
 2 s:/C=US/O=GeoTrust Inc./CN=GeoTrust Global CA
   i:/C=US/O=Equifax/OU=Equifax Secure Certificate Authority
-----BEGIN CERTIFICATE-----
<<still more alphabet soup>>
-----END CERTIFICATE-----
---
Server certificate
subject=/C=US/ST=California/L=Mountain View/O=Google Inc/CN=*.google.com
issuer=/C=US/O=Google Inc/CN=Google Internet Authority G2
---
No client certificate CA names sent
---
SSL handshake has read 4459 bytes and written 435 bytes
---
New, TLSv1/SSLv3, Cipher is AES128-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
    Protocol  : TLSv1
    Cipher    : AES128-SHA
    Session-ID: 04FEFFB1D8878D14520CEC7038A3C8F0A784D48043884C03527248C57D9D105C
    Session-ID-ctx: 
    Master-Key: 437E5B5591599F26D006F81714B2CA589561B61523E96BDF2050568C16B1E53172BC9CA3306E0B1DFF791DCAAEF73CE3
    Key-Arg   : None
    TLS session ticket lifetime hint: 100800 (seconds)
    TLS session ticket:
    0000 - 00 c9 04 b0 fe 98 9c 0c-1e 9c d4 16 e8 7a 16 cb   .............z..
    0010 - db da f9 f3 fe f2 70 55-7a 02 3f ba ac 60 1d 93   ......pUz.?..`..
    0020 - 5a 3a d7 8e fb 34 34 a8-12 1b 66 f1 b7 9c 2b 4c   Z:...44...f...+L
    0030 - c5 27 07 26 db 84 74 79-73 b0 47 40 cb 97 67 85   .'.&..tys.G@..g.
    0040 - e4 a5 9c 1b be 15 81 73-eb e7 c7 7e e7 c5 ad 69   .......s...~...i
    0050 - f2 db 22 df 21 36 0a 34-cc 23 96 e4 e6 2e b8 1c   ..".!6.4.#......
    0060 - 3b 82 26 65 97 41 19 0a-1e 6e 24 e1 14 61 18 1b   ;.&e.A...n$..a..
    0070 - 93 f6 f2 8e e0 d0 ec 49-0f cd 83 94 94 fe a6 f9   .......I........
    0080 - 7e 3c b5 47 2c 7a 85 cd-47 ed 6d 8a 8c 79 a4 95   ~<.G,z..G.m..y..
    0090 - 0d 43 61 ea a5 6a 9d cc-b9 96 a2 df 92 84 97 3c   .Ca..j.........<
    00a0 - c1 9c e1 0c 4c ac b2 2d-2e b6 b9 ba 74 16 66 4b   ....L..-....t.fK
    00b0 - d4 a9 fc e4 9c b9 9b a1-5e 49 ab 7c 72 4d f0 a8   ........^I.|rM..
    00c0 - f0 c7 b8 bc 2a 0b df f9-a4 35 a4 a7 6d c4 9b 96   ....*....5..m...

    Start Time: 1499146235
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---
That's about everything there is to know about the SSL/TLS connection negotiation. It includes the server's certificate, and all the parent CA certificates the contacted server cared to supply.

Note that the in my example, *.google.com certificate is certified by "Google Internet Authority G2" (i.e. Google's own CA), which is in turn certified by GeoTrust, which is certified by Equifax. I have a hunch that your output may seem somewhat different there.

To decode the server's certificate to human-readable state, you can then use another command:
code:
openssl x509 -noout -text -certopt no_pubkey,no_sigdump,no_header,ext_parse -in ~/Desktop/ssl-diag.txt
It should output something like this:
code:
        Version: 3 (0x2)
        Serial Number:
            26:79:b3:36:94:25:39:b2
        Signature Algorithm: sha256WithRSAEncryption
        Issuer: C=US, O=Google Inc, CN=Google Internet Authority G2
        Validity
            Not Before: Jun 21 14:10:54 2017 GMT
            Not After : Sep 13 13:52:00 2017 GMT
        Subject: C=US, ST=California, L=Mountain View, O=Google Inc, CN=*.google.com
        X509v3 extensions:
            X509v3 Extended Key Usage: 
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Subject Alternative Name: 
                DNS:*.google.com, DNS:*.android.com, DNS:*.appengine.google.com, 
DNS:*.cloud.google.com, DNS:*.db833953.google.cn, DNS:*.g.co, DNS:*.gcp.gvt2.com, 
DNS:*.google-analytics.com, DNS:*.google.ca, DNS:*.google.cl, DNS:*.google.co.in, 
DNS:*.google.co.jp, DNS:*.google.co.uk, DNS:*.google.com.ar, DNS:*.google.com.au, 
DNS:*.google.com.br, DNS:*.google.com.co, DNS:*.google.com.mx, DNS:*.google.com.tr, 
DNS:*.google.com.vn, DNS:*.google.de, DNS:*.google.es, DNS:*.google.fr, DNS:*.google.hu, 
DNS:*.google.it, DNS:*.google.nl, DNS:*.google.pl, DNS:*.google.pt, DNS:*.googleadapis.com, 
DNS:*.googleapis.cn, DNS:*.googlecommerce.com, DNS:*.googlevideo.com, DNS:*.gstatic.cn, 
DNS:*.gstatic.com, DNS:*.gvt1.com, DNS:*.gvt2.com, DNS:*.metric.gstatic.com, DNS:*.urchin.com, 
DNS:*.url.google.com, DNS:*.youtube-nocookie.com, DNS:*.youtube.com, DNS:*.youtubeeducation.com, 
DNS:*.yt.be, DNS:*.ytimg.com, DNS:android.clients.google.com, DNS:android.com, 
DNS:developer.android.google.cn, DNS:developers.android.google.cn, DNS:g.co, DNS:goo.gl, 
DNS:google-analytics.com, DNS:google.com, DNS:googlecommerce.com, DNS:source.android.google.cn, 
DNS:urchin.com, DNS:www.goo.gl, DNS:youtu.be, DNS:youtube.com, 
DNS:youtubeeducation.com, DNS:yt.be
            Authority Information Access: 
                CA Issuers - URI:http://pki.google.com/GIAG2.crt
                OCSP - URI:http://clients1.google.com/ocsp

            X509v3 Subject Key Identifier: 
                BF:CD:7D:2C:EC:36:66:82:64:57:80:32:C1:B1:62:FC:90:6E:12:9D
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Authority Key Identifier: 
                keyid:4A:DD:06:16:1B:BC:F6:68:B5:76:F5:81:B6:BB:62:1A:BA:5A:81:2F

            X509v3 Certificate Policies: 
                Policy: 1.3.6.1.4.1.11129.2.5.1
                Policy: 2.23.140.1.2.2

            X509v3 CRL Distribution Points: 
                URI:http://pki.google.com/GIAG2.crl

This is all from the first alphabet soup part in the file. If you want to analyze the other certificates in the ssl-diag.txt file, you can make a copy of the file, then edit the copy to cut off the first alphabet soup part, including its "-----BEGIN CERTIFICATE-----" and "-----END CERTIFICATE-----" lines. Then you can use the previous command on the modified copy to decode the second certificate listed. Rinse and repeat for any other certificates within.

Whew. If you got through all of that, you now have the commands to get just about all the information a SSL/TLS client can get about a server and its certificate by just connecting to it. Use them wisely, and feel free to ask if you find anything suspicious-looking: there are quite a bit of tricky details in SSL/TLS at this level.

  • Locked thread