curl and openssl видят разные эмитенты

Question

Я очень смущен этим, и, без сомнения, это мое недоразумение или некоторые такие, но я пытаюсь заставить свою машину говорить с прокси-сервером вверх, я использую redsocks для прозрачно перенаправлять на восходящий поток.

Ниже мы можем увидеть завиток

root@Amachine:/# curl -v -k https://bower.herokuapp.com 
* Rebuilt URL to: https://bower.herokuapp.com/ 
* Hostname was NOT found in DNS cache 
* Trying 54.235.187.231... 
* Connected to bower.herokuapp.com (54.235.187.231) port 443 (#0) 
* successfully set certificate verify locations: 
* CAfile: none 
    CApath: /etc/ssl/certs 
* SSLv3, TLS handshake, Client hello (1): 
* SSLv3, TLS handshake, Server hello (2): 
* SSLv3, TLS handshake, CERT (11): 
* SSLv3, TLS handshake, Server key exchange (12): 
* SSLv3, TLS handshake, Server finished (14): 
* SSLv3, TLS handshake, Client key exchange (16): 
* SSLv3, TLS change cipher, Client hello (1): 
* SSLv3, TLS handshake, Finished (20): 
* SSLv3, TLS change cipher, Client hello (1): 
* SSLv3, TLS handshake, Finished (20): 
* SSL connection using TLSv1.2/ECDHE-RSA-AES256-SHA 
* Server certificate: 
*  subject: C=US; ST=California; L=San Francisco; O=Heroku, Inc.; CN=*.herokuapp.com 
*  start date: 2014-01-21 00:00:00 GMT 
*  expire date: 2017-05-19 12:00:00 GMT 
*  issuer: CORPORATE PROXY 

Эмитент, как представляется, корпоративный прокси. Нарушение всех сообщений ssl.

root@machine:/# openssl s_client -connect bower.herokuapp.com:443 
CONNECTED(00000003) 
depth=1 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert SHA2 High Assurance Server CA 
verify error:num=20:unable to get local issuer certificate 
verify return:0 
--- 
Certificate chain 
0 s:/C=US/ST=California/L=San Francisco/O=Heroku, Inc./CN=*.herokuapp.com 
    i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA 
1 s:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert SHA2 High Assurance Server CA 
    i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert High Assurance EV Root CA 

Что меня озадачивает, так это то, что у них разные эмитенты. Предоставленный завиток, кажется, скрывает большую часть того, что происходит. Я могу указать корневой путь ca и openssl, и дает мне хорошо, но curl каким-то образом использует другой путь.

Я действительно не уверен, как отлаживать то, что происходит на земле в curl. Я думал, что у меня получится аналогичный эмитент. Возможно, я не понимаю, как работает s_client, кто-нибудь знает, что происходит?

Answer 1

У вас есть прокси-сервер перехвата SSL в вашей сети, и завиток использует его, в то время как openssl не использует его, или прокси не перехватывает соединения. Это не ясно из вашего описания, что дело в точности, но это может быть

• , что вы используете разные машины, и от одного соединения получают перехвачены, а с другой не
• , что перехватывают прокси будет не перехватывать соединения без указания имени сервера (SNI). Curl выполняет SNI, а openssl - не так, как вы его используете. Используйте аргумент -servername, чтобы повторить попытку с помощью SNI.

Answer 2

1) Вы использовали параметр -k для завивки, что заставляет его игнорировать CA-проверку, но по крайней мере она показывает, в чем проблема, прокси-сервер MITM SSL.

Предположительно вы не можете обойти его, в этом случае лучшим вариантом может быть извлечение САЦ «CORPORATE PROXY» и сделать его доверенным ЦС на вашей рабочей станции. Это, как правило, не очень хорошая идея, так как это разрушает любые усилия, предпринятые CA для проверки предмета сертификата. С другой стороны, корпоративные сети обычно принимают такое решение для вас в любом случае.

2) openssl жалуется только на то, что он не проверяет цепочку CA по умолчанию. Также кажется, что вы не в той же сети и/или используете другой набор прокси, чем с curl. Вы можете узнать это, если вы проверяете условия для http_proxy или аналогичных:

# printenv|egrep -i '(http|proxy)' 

Или, если все остальное терпит неудачу, возможно, локон вы используете замоноличен использовать различный сокс, вы можете проверить трассирование, к которому подключается IP-адрес curl и openssl. Посмотрите на использование подключения системных вызовов с:

# strace -f -e connect curl https://www.google.com:443 

Как уже упоминалось, OpenSSL необходим параметр -CApath CERTIFICATEDIR для проверки эмитентов с ЦС сертификатов, специально указанных в CERTIFICATEDIR. Кроме CERTIFICATEDIR, это фактически проверка каталога сертификат системы, а также, который был обеспечен за счет распределения - так как ярлык, как-то просто, как правило, работают:

# openssl s_client -CApath 1 -connect bower.herokuapp.com:443 

1 будет проверяться как каталог для сертификатов, но если его не существует, с системой будут проведены консультации.Другие полезные опции, которые вы можете найти в руководстве по эксплуатации s_client

-servername SNI 

Пошлют вариант имени хоста в исходном пакете ClientHello так, что сервер (и корпоративный прокси-сервер) могут лучше решить, какой сертификат использовать на хосте.

-CAfile FILE 

Если вы знаете, что для подключения имеется только один приемлемый ЦС.

-showcerts 

Если вы хотите записать и проанализировать все сертификаты в формате PEM.

-status 

Он просит сервер предоставить статус OCSP своего собственного сертификата через OCSP сшивание и OpenSSL будет проверять, если он действителен.