I cant find a way to reach out to whoever manages ARO directly so I figure it would be best to publish this to the list. We are a group of network operators who are failing at enforcing extremely basic security in our own applications. 1.) Retrieving an ARO password sends a plain text email of your current password. Im sure this is minor as its just ARO and none of us would ever re-use a password in more critical systems. 2.) The SSL cert for secretariat.nanog.org is invalid. It looks to be trying to use the wildcard for amsl.com $ openssl s_client -showcerts -connect secretariat.nanog.org:443 CONNECTED(00000003) depth=0 /OU=Domain Control Validated/CN=*.amsl.com verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 /OU=Domain Control Validated/CN=*.amsl.com verify error:num=27:certificate not trusted verify return:1 depth=0 /OU=Domain Control Validated/CN=*.amsl.com verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/OU=Domain Control Validated/CN=*.amsl.com i:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./OU= http://certs.starfieldtech.com/repository//CN=Starfield Secure Certificate Authority - G2
On Mon, May 18, 2015 at 12:30 PM, Nicholas Schmidt < nicholas.schmidt@controlgroup.com> wrote:
I cant find a way to reach out to whoever manages ARO directly so I figure it would be best to publish this to the list.
Nicholas, It's normally a good idea to email any questions you have to nanog-support@nanog.org. They should always get you an answer or point you in the correct direction. We are a group of network operators who are failing at enforcing extremely
basic security in our own applications.
1.) Retrieving an ARO password sends a plain text email of your current password. Im sure this is minor as its just ARO and none of us would ever re-use a password in more critical systems.
This is a known problem and I assure you NANOG is working with their vendor to address it.
2.) The SSL cert for secretariat.nanog.org is invalid. It looks to be trying to use the wildcard for amsl.com
I'm curious what is going on, but I wonder if it doesn't have something to do with the openssl command you've entered below. When using firefox, chrome, or safari from my laptop and internet explorer from within a VM, I'm being offered the *.nanog.org wildcard cert, not an amsl.com cert. I checked a popular online ssl certificate checker and similarly received the proper certificate. Are you receiving a certificate error of some type in your browser? If so, let's take the conversation off of nanog to spare the list. -e
$ openssl s_client -showcerts -connect secretariat.nanog.org:443
CONNECTED(00000003)
depth=0 /OU=Domain Control Validated/CN=*.amsl.com
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 /OU=Domain Control Validated/CN=*.amsl.com
verify error:num=27:certificate not trusted
verify return:1
depth=0 /OU=Domain Control Validated/CN=*.amsl.com
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
0 s:/OU=Domain Control Validated/CN=*.amsl.com
i:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./OU= http://certs.starfieldtech.com/repository//CN=Starfield Secure Certificate Authority - G2
i too get the amsl cert in response to an opelssl cert query with a bog standard starfield class 2 chain % openssl s_client -connect secretariat.nanog.org:443 CONNECTED(00000003) depth=0 /OU=Domain Control Validated/CN=*.amsl.com verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 /OU=Domain Control Validated/CN=*.amsl.com verify error:num=27:certificate not trusted verify return:1 depth=0 /OU=Domain Control Validated/CN=*.amsl.com verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/OU=Domain Control Validated/CN=*.amsl.com i:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./OU=http://certs.starfieldtech.com/repository//CN=Starfield Secure Certificate Authority - G2 1 s:/C=US/ST=Arizona/L=Scottsdale/O=Starfield Technologies, Inc./OU=http://certificates.starfieldtech.com/repository/CN=Starfield Secure Certification Authority/serialNumber=10688435 i:/C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification Authority 2 s:/C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification Authority i:/C=US/O=Starfield Technologies, Inc./OU=Starfield Class 2 Certification Authority --- Server certificate -----BEGIN CERTIFICATE----- MIIGRDCCBSygAwIBAgIJAInJ3xG7x0IgMA0GCSqGSIb3DQEBCwUAMIHGMQswCQYD with chrome, https://secretariat.nanog.org gets me a redirect to the insecure http://www.nanog.org/ (note lack of 's') via the tls-failing cert, see above
let's take the conversation off of nanog to spare the list.
one of the purposes of this list is for us to learn from eachother. in this case, techniques for diagnosing tls & cert issues are worth sharing. [ sadly, folk with bugs love to redirect discussion off public media ] randy
On Mon, May 18, 2015 at 4:40 PM, Randy Bush <randy@psg.com> wrote:
let's take the conversation off of nanog to spare the list.
one of the purposes of this list is for us to learn from eachother. in this case, techniques for diagnosing tls & cert issues are worth sharing. [ sadly, folk with bugs love to redirect discussion off public media ]
$ openssl s_client -servername www.nanog.org -connect www.nanog.org:443 CONNECTED(00000003) depth=3 C = US, O = "The Go Daddy Group, Inc.", OU = Go Daddy Class 2 Certification Authority .... stuff.... subject=/OU=Domain Control Validated/CN=*.nanog.org issuer=/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2 .... stuff ..... (I think you need to send along: -servername)
(I think you need to send along: -servername)
point % openssl s_client -servername secretariat.nanog.org -connect secretariat.nanog.org:443 CONNECTED(00000003) depth=3 /C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority verify error:num=19:self signed certificate in certificate chain verify return:0 --- Certificate chain 0 s:/OU=Domain Control Validated/CN=*.nanog.org i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2 1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2 i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2 2 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2 i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority 3 s:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority --- Server certificate -----BEGIN CERTIFICATE----- mehr beßer
of course, this begs the question of why one would try to go to https://secretariat.nanog.org/. it is published as a supported web site? randy
On Mon, May 18, 2015 at 3:59 PM, Eric Oosting <eric.oosting@gmail.com> wrote:
On Mon, May 18, 2015 at 12:30 PM, Nicholas Schmidt < nicholas.schmidt@controlgroup.com> wrote:
2.) The SSL cert for secretariat.nanog.org is invalid. It looks to be trying to use the wildcard for amsl.com
I'm curious what is going on, but I wonder if it doesn't have something to do with the openssl command you've entered below.
$ openssl s_client -showcerts -connect secretariat.nanog.org:443
Hi Eric, It does and it doesn't. The following openssl command gets the correct cert: openssl s_client -servername secretariat.nanog.org -showcerts -connect secretariat.nanog.org:443 The -servername parameter tells openssl to use the SSL Server Name Indication extension. This allows multiple HTTPS web sites to live on the same IP address much as the HTTP 1.1 Host header allowed multiple regular HTTP web sites to live on the same IP address. All "modern" web browsers support SNI. "Modern" doesn't go back terribly far. "Older" implementations of HTTPS will get the wrong certificate as shown. So, if you want to maximize compatibility, have a talk with your vendor about a dedicated IP address for your HTTPS server. Otherwise, make a note in your documentation that SSL clients must support the SNI extension to use the web site. Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/>
participants (5)
-
Christopher Morrow -
Eric Oosting -
Nicholas Schmidt -
Randy Bush -
William Herrin