IBM-Cloud / ibm-cloud-developer-tools

Installation scripts for new IBM Cloud Developer CLI Plugin and it's dependencies.
Apache License 2.0
131 stars 146 forks source link

Please Fix your SSL installation #60

Closed bizmate closed 6 years ago

bizmate commented 6 years ago

Summary I am trying to install tools ahead of an IBM event and I have stepped into one of the most basic problems I would have not expected. The SSL certificates are not configured correctly on the installer site.

Steps to reproduce (include tooling version, platform, etc)

  1. curl -sL https://ibm.biz/idt-installer | bash does nothing
  2. curl -L https://ibm.biz/idt-installer shows curl: (60) SSL certificate problem: unable to get local issuer certificate

Operating System MacOS 10.13.5

Supporting details See SSL problems at https://www.ssllabs.com/ssltest/analyze.html?d=ibm.biz

triceam commented 6 years ago

Slightly confused by this issue... you should still be able to pull from the link, granted, the cert does need to be updated. What region are you in? Perhaps this is something region-specific. The CLI & installer team doesn't own the ibm.biz domain, so I'll forward this on to the appropriate team.

I am able to fetch the installation script without issue using curl -L https://ibm.biz/idt-installer:

image

triceam commented 6 years ago

Submitted a bug report through W3 feedback and also posted about this in Snip forums at: https://w3-connections.ibm.com/forums/html/topic?id=d36ab2fd-0549-425c-b24c-2fb6842dc9f5 (only accessible inside the firewall).

bizmate commented 6 years ago

@triceam is your curl configured to skip SSL checks?

$ curl -L https://ibm.biz/idt-installer
curl: (60) server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
More details here: http://curl.haxx.se/docs/sslcerts.html

The initial report was from mac, now i have run it also from Ubuntu. What is the configuration of your curl library? ie

$ curl-config --configure
 '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=/usr/include' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-silent-rules' '--libdir=/usr/lib/x86_64-linux-gnu' '--libexecdir=/usr/lib/x86_64-linux-gnu' '--disable-maintainer-mode' '--disable-dependency-tracking' '--disable-symbol-hiding' '--enable-versioned-symbols' '--enable-threaded-resolver' '--with-lber-lib=lber' '--with-gssapi=/usr' '--with-zsh-functions-dir=/usr/share/zsh/vendor-completions' '--with-ca-path=/etc/ssl/certs' '--with-ca-bundle=/etc/ssl/certs/ca-certificates.crt' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security' 'LDFLAGS=-Wl,-Bsymbolic-functions -fPIE -pie -Wl,-z,relro -Wl,-z,now -Wl,--as-needed' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'

The difference but be in the configuration of your local machine. If you see the SSL Labs link it shows clearly some of the issues with the SSL config on the site

steveclay commented 6 years ago

@bizmate I don't see anything set in my env that would ignore SSL for curl and I am able to run the installer from a Mac. My curl version is as follows:

curl --version
curl 7.54.0 (x86_64-apple-darwin17.0) libcurl/7.54.0 LibreSSL/2.0.20 zlib/1.2.11 nghttp2/1.24.0
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtsp smb smbs smtp smtps telnet tftp 
Features: AsynchDNS IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz HTTP2 UnixSockets HTTPS-proxy

Do you see a difference with your own curl version config?

bizmate commented 6 years ago

@steveclay my mac has a slightly older 7.52 version, however by just looking at the version is very difficult to prove the outstanding issue with the SSL certificate because clients can all be configured in different ways but if some clients are set up and run strict checks (for security) they should be ensured the SSL configuration is up to standards. SSL Labs is the tool i use for reference as SSL configuration can sometimes still work even if roots and ca are not well configured but command line tools (like curl) can be stricter as they value security, in general, up to a much higher level.

The only thing I can suggest for you to reproduce the problem, if you dont trust SSL Labs, is to use docker as images guarantee a certain degree of parity/reproducibility at 100%

  1. on your host docker run -ti ubuntu /bin/bash
  2. inside the container apt-get update && apt-get install curl && curl -L https://ibm.biz/idt-installer and see the error

Also inside the container

root@0435e5cb4d15:/# curl --version
curl 7.58.0 (x86_64-pc-linux-gnu) libcurl/7.58.0 OpenSSL/1.1.0g zlib/1.2.11 libidn2/2.0.4 libpsl/0.19.1 (+libidn2/2.0.4) nghttp2/1.30.0 librtmp/2.3
Release-Date: 2018-01-24
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp smb smbs smtp smtps telnet tftp 
Features: AsynchDNS IDN IPv6 Largefile GSS-API Kerberos SPNEGO NTLM NTLM_WB SSL libz TLS-SRP HTTP2 UnixSockets HTTPS-proxy PSL
triceam commented 6 years ago

I'm on the same version of curl as @steveclay, and seeing the same thing. That said, I'm able to recreate it using docker/ubuntu like you mentioned. We (meaning Steve and I) don't own the ibm.biz domain, so I've filed a bug report with the IBM Help Desk to have this looked into.

That said, you can also run the exact same command over http instead of https and it should work. Our workaround until the cert is fixed could be to just have users pull content over http (we'll need to update docs). There are no credentials or other secure information in the script that would compromise the end user.

triceam commented 6 years ago

Issue verified and forwarded to CIO office. We don't see the issue b/c IBM devices are pre-provisioned to accept the cert.

From the forums thread:

I've forwarded this issue to the CIO Cloud team that handles the infrastructure, seems that the root/intermediate CAs for ibm.biz is not properly configured. However IBM provisioned devices would work because our provisioning process configures the SSL stores automatically for any internal / external CAs we use.

triceam commented 6 years ago

Appears to be fixed from SNIP team. We can switch back to https urls.

steveclay commented 6 years ago

In the meantime, the install instructions have been changed to not use https. I think we can close this, as this removes the problem.