Ingen SSLv2 i 12.04 men PHP forsøger stadig og fejler

[AJenbo]

Hej efter jeg har opgraderet en server fra 11.10 til 12.04 kan jeg ikke længere få SSL (HTTPS) til at virke med SOAP (soapClient) og cURL (curl_init) i PHP. Jeg har fået sporet mig frem til at det er pga. de forsøger at forbinde via SSLv2 selv om den er blevet fjernet fra openSSL.

Kode: Vælg alt

$ php -i | grep ssl
Registered Stream Socket Transports => tcp, udp, unix, udg, ssl, sslv3, tls
openssl


Problemet kan omgås ved at tvinge cURL til at bruge ssl:

Kode: Vælg alt

        curl_setopt($curl, CURLOPT_SSLVERSION, 3);

samt lave en wrapper til SOAP og bruge den i stedet:

Kode: Vælg alt

class SoapClientSSLv3 extends SoapClient {
  protected function callCurl($url, $data) {
     $handle   = curl_init();
     curl_setopt($handle, CURLOPT_URL, $url);
     curl_setopt($handle, CURLOPT_HTTPHEADER, Array("Content-Type: text/xml") );
     curl_setopt($handle, CURLOPT_RETURNTRANSFER, true);
     curl_setopt($handle, CURLOPT_POSTFIELDS, $data);
     curl_setopt($handle, CURLOPT_SSLVERSION, 3);
     $response = curl_exec($handle);
     if (empty($response)) {
       throw new SoapFault('CURL error: '.curl_error($handle),curl_errno($handle));
     }
     curl_close($handle);
     return $response;
   }

   public function __doRequest($request,$location,$action,$version,$one_way = 0) {
       return $this->callCurl($location,$request);
   }
}


Dette kræver dog at jeg laver ændringer ved koden hvilket jeg helst vil undgå, jeg oplever heller ikke problemet på en maskine hvor jeg har lavet en ren installation af PHP 12.04.

[AJenbo]

Ved nærmere undersøgelse viser det sig at det er nogle sider der virker og andre der ikke gøre:

https://mds.datacite.org/ virker ikke:

Kode: Vælg alt

        $curl = curl_init();
        curl_setopt($curl, CURLOPT_RETURNTRANSFER, true);
        curl_setopt($curl, CURLOPT_HEADER, false);
        curl_setopt(
            $curl,
            CURLOPT_URL,
'https://mds.datacite.org/'
        );
        $response = curl_exec($curl);
var_dump($response);

https://www.google.dk/ virker:

Kode: Vælg alt

        $curl = curl_init();
        curl_setopt($curl, CURLOPT_RETURNTRANSFER, true);
        curl_setopt($curl, CURLOPT_HEADER, false);
        curl_setopt(
            $curl,
            CURLOPT_URL,
'https://www.google.dk/'
        );
        $response = curl_exec($curl);
var_dump($response);

[Christian.Arvai]

Hej Anders

Jeg ved intet om det, men Lars (lath) har været online på irc det meste af dagen, og jeg skal se om jeg kan fange ham senere.

[lath]

Hej Anders

Ved SSL er det hver side af kommunikation der i et SSL handshake bliver enig om både hvilken SSL protokol type, der skal bruges, og antal bits der indgår i krypteringen.

Hver part i kommunikationen kan afvise den anden part ved dårlig kryptering (for lavt antal bits) og/eller SSL protokoltype, der måske kan regnes for usikker af den part.
En afvisning sker mest sikkert og nemmest ved simpelthen ikke at implementere den del/de dele man ikke vil understøtte - dvs altså ved oversættelsen af kildekode med en compiler udelader man det man ikke vil understøtte.

Et SSL handshake:


Det jeg så mener at der sker er at Google SSLs handshaket så kan acceptere næsten alt, måske lige bortset fra den svageste kryptering, så går det godt.
I dit andet tilfælde hvorimod det andet site (mds.datacite.org) du prøvede op imod måske kun bruger TLS, og mange bits, og så kan din del af SSL kommunikationen give op, hvis den ikke opfylde det den anden accepterer som minimumskrav. Du kan også blive afvist af den anden part. Der er også en chance for at mds.datacite.org certificat checket fortæller din side af SSL kommunikationen at certikatet ikke er godt, og kommunikationen derfor skal droppes med den server.

Debugging
phpinfo
phpinfo kan nok give noget info om hvad den understøtter af SSL protokol typer+antal af bits i krypteringen.

Wireshark og tcpdump
Wireshark kan hjælpe med at dekryptere din SSL kommunikation, hvis du giver programmet din private nøgle.

Jeg foreslår at du bruger wireshark og konsolprogrammet tcpdump i kombination. Begge kan optage og gemme i samme libpcap format.
Ideen er så at du først optager kommunikation, og så gemme den i libpcap formatet på din server.
Derefter kan du hente filen ned til en maskine med en desktop (Ubuntu, Windows, og Mac OS X er fint) også starte Wireshark - give wireshark den privat SSL nøgle der bruges af din server.
Nu kan Wireshark dekryptere din side af SSL kommunikationen, og så kan du se hvad der går galt ved at lave protokol analyse.

andre SSL værktøjer
Der er næsten helt sikkert også dedikerede SSL protokol værktøjer. Det er dog ikke noget jeg har undersøgt nærmere.
opennsl kommandoen er dog meget oplagt at tage fat i, og prøve at få den til at spytte al det debugging information ud man kunne ønske sig ned i en fil.

ltrace
http://manpages.ubuntu.com/manpages/precise/man1/ltrace.1.html

Du kan også få en god ide om hvad PHP har gang i ved at bruge et værktøj der hedder ltrace. ligesom strace der kan trace systemkald til kernen kan ltrace trace kald ned til et bestemt softwarebibliotek, i dit tilfælde er du interesseret i kommunikationen imellem OpenSSL biblioteket og PHP fortolkeren.

Det ekstra smarte ved ltrace sammen med OpenSSL er at du får al kommunikation i klartekst (ukrypteret), og derfor nemmere får en ide om hvor kæden hopper af.

Glem ikke at bruge --demangle, hvis OpenSSL biblioteket er et C++ softwarebibliotek.

Ubuntu Community help, OpenSSL
https://help.ubuntu.com/community/OpenSSL/

Nogle af advarslerne er ret interessant læsning.

OpenSSL.org
FAQ er måske interessant læsning, når du får nogle resultater fra din SSL debugging: http://www.openssl.org/support/faq.html

/Lars

[AJenbo]

Tjo den del har jeg sådan set allerede forstået og været igennem. Det store problem er at PHP ved forhandling om der skal bruges SSLv2 eller SSLv3 ved visse servere ender ud i at ville bruge SSLv2 selv om det ikke er implementeret og heller ikke registeret med php (se mit output fra php -i), og på tross at SSLv3 også er en mulighed. Jeg skriver godt nok at jeg ikke er meget for at skulle patche webside koden, men jeg er endnu mindre for at skulle patche selve PHP så jeg håber lidt på at dette kan løse ved en konfiguration.

[lath]

Tjo den del har jeg sådan set allerede forstået og været igennem.

Det store problem er at PHP ved forhandling om der skal bruges SSLv2 eller SSLv3 ved visse servere ender ud i at ville bruge SSLv2 selv om det ikke er implementeret og heller ikke registeret med php (se mit output fra php -i), og på tross at SSLv3 også er en mulighed.

Jeg skriver godt nok at jeg ikke er meget for at skulle patche webside koden, men jeg er endnu mindre for at skulle patche selve PHP så jeg håber lidt på at dette kan løse ved en konfiguration.

Jeg fik - indrømmet - læst det lidt rigeligt hurtigt..

Dit problem er altså at der ikke er nogen SSLv2 i OpenSSL.
Det løses med konfiguration, men nok ikke lige som du helst ville gøre det.


Der er andre SSL libs end OpenSSL.

Er SSLv2 vigtigt for dig kan du så finde sådan et andet SSL lib, og lave en PHP binding med SWIG. PHP bindingens kildekode laves fuldautomatisk af SWIG, når du først har lavet en config til opgaven der virker:

Andre SSL libs er:

• PolarSSL http://www.polarssl.org//*:m/*:m/*:m/*:m/*:m/*:m/*:m/*:m
  
• CyaSSL http://www.yassl.com/yaSSL/Home.html/*:m/*:m/*:m/*:m/*:m/*:m/*:m
  
• MatrixSSL http://www.matrixssl.org//*:m/*:m/*:m/*:m/*:m/*:m/*:m
  
• NSS http://www.mozilla.org/projects/security/pki/nss/ , og
• GnuTLS http://www.gnu.org/software/gnutls/

Af dem står der i http://en.wikipedia.org/wiki/Comparison_of_TLS_Implementations at kun OpenSSL og NSS understøtter SSLv2.
Du siger at OpenSSL har fjernet SSLv2, hvilket lyder rigtigt, da den protokol type af SSL er demonstreret til at være usikker, AFAIK.
Så er der kun NSS fra Mozilla tilbage. NSS er det SSL bibliotek der bruges i Firefox, Thunderbird.
Dens afhængigheder skulle være: libc, libnspr4, libsoftokn3, libplc4, libplds4. Kun zlib er optionalt - brug den kun hvis du vil have komprimering med.
I Ubuntu skal du også installere -dev pakkerne for at kunne oversætte fra kilde kode til en .so fil, som du ligger i en af de mapper som LIB miljøvariablen peger på.
Til sidst kører ldd-config for at opdatere den dynamiske linkers cache af software biblioteker.

Jeg ved heller ikke om den har en PHP binding til NSS, ellers må du lave den selv med SWIG:

• Om SWIG selv: http://www.swig.org/
• Om at lave en PHP binding med SWIG: http://www.swig.org/Doc1.3/Php.html

Du er lidt heldig. Der er et software bibliotek der kan lege OpenSSL på den ene side, men i virkelighed kalder NSS.
Den adapter hedder nss_compat_ossl: http://fedoraproject.org/wiki/Nss_compat_ossl
Nu er øvelsen reduceret til at lave en SWIG binding til nss_compat_ossl, fordi du så får nogen der i PHP fortolkeren ligner at det er OpenSSL, hvorved at dit PHP framework der bruger OpenSSL kan bruge det uden ændringer, i teorien altså.

Du oversætter så PHP fortolkeren sammen SWIG binding koden til nss_compat_ossl, og husker ved samme lejlighed også at linke både nss_compat_ossl og NSS softwarebibliotekerne ind i PHP fortolkeren.

Er du heldig så findes der binær pakke af NSS så du slipper for at oversætte den fra kildekode, og en nss-dev pakke der lader dig bruge det NSS i ny kode (nss_compat_ossl). Er du rigtig heldig er der også en binær og dev pakke til nss_compat_ossl.

---

Det sværeste for dig bliver at lave en SWIG konfiguration der både i PHP syntax (den måde kode skrives på) og især i PHP semantik (den måde kode opfører sig) bliver helt identisk med OpenSSL PHP bindingen.

Når det lykkedes kan du som jeg før nævnte bruge nss_compat_ossl bindingen som en fuldstændig erstatning for OpenSSL. Oven i købet kan du konfigurere den sådan at den information der returneres i f.eks phphinfo er nøjagtige den samme som den fra OpenSSL.
Det betyder så at et PHP framework der har en afhængighed til OpenSSL både snydes til at tro at den arbejder med OpenSSL, men også at det rent faktisk virker som OpenSSL.

---

Alternativt, hvis nss_compat_ossl er lidt for langhåret, så laver du i stedet en PHP binding til NSS med SWIG.
I PHP kode laver så du en adapter, http://www.netobjectivestest.com/PatternRepository/index.php?title=TheAdapterPattern.
Den skal selvfølgelig have et PHP interface, (syntax, og med samme semantik) der svarer til OpenSSL PHP bindingen.
Den PHP adapter kode bruger så PHP bindingen til NSS.

/Lars

[AJenbo]

SSLv2 er blevet fjernet af sikkerhedsmæssige årsager og jeg kan fint bruge SSLv3. Jeg har set på nettet at andre har løst det ved at vælge en mere avanceret chiper, men jeg ved ikke hvor det gøres.

[lath]

SSLv2 er blevet fjernet af sikkerhedsmæssige årsager og jeg kan fint bruge SSLv3. Jeg har set på nettet at andre har løst det ved at vælge en mere avanceret chiper, men jeg ved ikke hvor det gøres.

Du må kunne sætte de krypteringsalgoritmer du må bruges i en SSL kommunikation, før der oprettes en forbindelse.
Det samme må være muligt, hvis SSL softwarebiblioteket bruges i en server (altså før accept kaldet køres).

Hvilken chiper du skal bruge ved jeg ikke.

/Lars

[AJenbo]

Ja, det er lidt denne mulighed jeg søger efter som en generel indstilling som må være sat forkert for php i Ubuntu 12.04. Ind jeg finder det må jeg nok ty til at bruge den kode jeg har i min første indlæg for hver server jeg forbinder til.