Czy moduł pytlona ssl poprawnie sprawdza poprawność certyfikatów? (Mam dziwny przykład, że mi przeszkadza)

Question

Problem:

ssl moduł Pythona nie narzeka certyfikatu, chociaż wydawania CA nie jest dostarczana w pliku cacert.pem (Test Case 2. poniżej). Używam CA wyodrębnionych z Mozilli. Firefox prawidłowo narzeka na nieznany CA (w tym przypadku Departament Obrony).

Wygląda na to, że tylko sam certyfikat jest sprawdzany, a nie, że CA jest znany. Używam Pythona 2.7.1 i korzystam z wersji ssl OpenSSL 0.9.8r.

przypadków testowych:

Sprawdź następujące strony w Firefoksie i na przykładzie Pythona klienta poniżej.

1. https://www.verisign.com - powinny działać, CA jest znane
2. https://www.us.army.mil - nie powinny działać, jak CA nie jest znana
3. https://www.pcwebshop.co.uk - nie powinny działać, tylko certyfikatowi Parallels panelu

przypadek 2. zostanie sprawdzony przez klienta Pythona, chociaż nie powinien.

Przypadek 3. zgłasza wyjątek zgodnie z oczekiwaniami:

routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed 

Przykład ten Python Klient:

plik CA: http://curl.haxx.se/ca/cacert.pem (domyślnie Mozilli urzędy przez opiekunów curl).

Nieco zmodyfikowana wersja http://docs.python.org/library/ssl.html#client-side-operation:

# test_ssl.py 
import socket, ssl, pprint, sys 
host = sys.argv[1] 

s = socket.socket(socket.AF_INET, socket.SOCK_STREAM) 

# require a certificate from the server 
ssl_sock = ssl.wrap_socket(s, 
          # http://curl.haxx.se/ca/cacert.pem 
          ca_certs="cacert.pem", 
          cert_reqs=ssl.CERT_REQUIRED) 

ssl_sock.connect((host, 443)) 

print repr(ssl_sock.getpeername()) 
print ssl_sock.cipher() 
print pprint.pformat(ssl_sock.getpeercert()) 

# Set a simple HTTP request -- use httplib in actual code. 
ssl_sock.write("""GET/HTTP/1.0\r 
Host: """ + host + """\r\n\r\n""") 

# Read a chunk of data. Will not necessarily 
# read all the data returned by the server. 
data = ssl_sock.read() 
print data 

# note that closing the SSLSocket will also close the underlying socket 
ssl_sock.close() 

Zastosowanie:

python test_ssl.py www.verisign.com 
python test_ssl.py www.us.army.mil 
python test_ssl.py www.pcwebshop.co.uk 

---

UPDATE:

Z pomocą strcat i innych mogę potwierdzić to zachowanie jest specyficzne dla:

• OSX Lion 10.7.1
• Python 2.7.1 Python 2.6.7 &
• OpenSSL 0.9.8r 8 Lut 2011

Testowałem na dwóch komputerach Mac i kilku innych polach. Podejrzewam, że OpenSSL na Macu używa drugiego źródła certyfikatów CA poza plikiem, który mu przekazuję. Może to sprawia, że ​​www.us.army.mil jest specjalną próbą, ponieważ Safari wydaje się ufać temu po wyjęciu z pudełka. Czy ktoś zna inne duże strony z autografami lub jak działa openssl na Mac?

Answer 1

Rozwiązaniem jest:

Poprzez testowanie mogę potwierdzić, że na OSX OpenSSL używa magazynu certyfikatów systemu CA, nawet jeśli nie podano, jak widać na przykładzie Pythona powyżej.

Użyłem www.us.army.mil jako egzemplarza testowego, ponieważ jest znane jako strona z autografem (http://royal.pingdom.com/2008/08/19/new-ssl-policy-in -bezpieczne-szkodliwe-dziesiątki-tysięcy stron /). Jak się okazuje, certyfikaty CA w systemie OSX zawierają dwa certyfikaty DoD, więc Safari nie uskarża się, a także mój klient testowy Pythona.

Gdybym niezaufanej tych świadectw w Keychan Access -> Roots systemowe -> Certyfikaty klient pyton pokazuje oczekiwane zachowanie, które potwierdza, że ​​python ssl/OpenSSL korzysta z certyfikatów głównych systemu OSX 10.7.1, czy na określony lub nie . Nie wiem, czy to jest oczekiwane zachowanie, ale z pewnością mnie zaskoczyło.

Answer 2

Firma Apple wprowadziła łatkę do swojej gałęzi OpenSSL, która wprowadziła tę możliwą lukę lub funkcję bezpieczeństwa, w zależności od tego, jak na to patrzysz. Zobacz tę poprawkę: http://www.opensource.apple.com/source/OpenSSL098/OpenSSL098-32/src/crypto/x509/x509_vfy_apple.c

Jednym ze sposobów obejścia tego problemu jest spakowanie aplikacji python za pomocą wersji openssl zbudowanej ze źródeł z openssl.org, która nie powinna mieć integracji z TEA.