🚀 go-pugleaf

On 01.07.2009, Andrzej Adam Filip wrote:
> Czy ktoś może zasugerować jak uzyskać uchwyt (handle) do połączenia SSL
> z możliwością sprawdzenia "odciska palca" klucza używanego przez serwer?
>
> Chce się łączyć z serwisem który używa samodzielnie generowanych kluczy

Klucze zawsze są generowane przez stronę serwującą usługę. Mówisz
o certyfikatach.

> i sprawdzanie przez Certification Authority zawsze "padnie".

Zawsze zawiedzie? Jeśli to certyfikaty tupu self-signed, to wystarczy
dodać sam certyfikat do CAfile/CApath. Jeśli to certyfikaty wydane przez
własne CA, to lepiej poproś o certyfikat tamtego CA.

-- 
Stanislaw Klekot

"Stachu 'Dozzie' K." <dozzie@dynamit.im.pwr.wroc.pl.nospam> pisze:

> On 01.07.2009, Andrzej Adam Filip wrote:
>> Czy ktoś może zasugerować jak uzyskać uchwyt (handle) do połączenia SSL
>> z możliwością sprawdzenia "odciska palca" klucza używanego przez serwer?
>>
>> Chce się łączyć z serwisem który używa samodzielnie generowanych kluczy
>
> Klucze zawsze są generowane przez stronę serwującą usługę. Mówisz
> o certyfikatach.
>
>> i sprawdzanie przez Certification Authority zawsze "padnie".
>
> Zawsze zawiedzie? Jeśli to certyfikaty tupu self-signed, to wystarczy
> dodać sam certyfikat do CAfile/CApath. Jeśli to certyfikaty wydane przez
> własne CA, to lepiej poproś o certyfikat tamtego CA.

Ja jestem zainteresowany akceptowaniem tylko certyfikatu jednego serwera.

-- 
Andrzej Adam Filip : anfi@onet.eu : Andrzej.Filip@gmail.com
Kto ziarno sieje, ten przed burzą zwieje.
  -- Przysłowie polskie (pl.wikiquote.org)

On 01.07.2009, Andrzej Adam Filip wrote:
> "Stachu 'Dozzie' K." <dozzie@dynamit.im.pwr.wroc.pl.nospam> pisze:
>
>> On 01.07.2009, Andrzej Adam Filip wrote:
>>> Czy ktoś może zasugerować jak uzyskać uchwyt (handle) do połączenia SSL
>>> z możliwością sprawdzenia "odciska palca" klucza używanego przez serwer?
>>>
>>> Chce się łączyć z serwisem który używa samodzielnie generowanych kluczy
>>
>> Klucze zawsze są generowane przez stronę serwującą usługę. Mówisz
>> o certyfikatach.
>>
>>> i sprawdzanie przez Certification Authority zawsze "padnie".
>>
>> Zawsze zawiedzie? Jeśli to certyfikaty tupu self-signed, to wystarczy
>> dodać sam certyfikat do CAfile/CApath. Jeśli to certyfikaty wydane przez
>> własne CA, to lepiej poproś o certyfikat tamtego CA.
>
> Ja jestem zainteresowany akceptowaniem tylko certyfikatu jednego serwera.

To to się robi callbackiem oceniającym akceptowalność certyfikatu
drugiej strony (tj. sprawdza poprawność atrybutu commonName). Co rzecz
jasna zakłada zaufanie wobec certificate authority. Sorry, Winetou,
that's the way X.509 works.

-- 
Stanislaw Klekot

"Stachu 'Dozzie' K." <dozzie@dynamit.im.pwr.wroc.pl.nospam> pisze:

> On 01.07.2009, Andrzej Adam Filip wrote:
>> "Stachu 'Dozzie' K." <dozzie@dynamit.im.pwr.wroc.pl.nospam> pisze:
>>
>>> On 01.07.2009, Andrzej Adam Filip wrote:
>>>> Czy ktoś może zasugerować jak uzyskać uchwyt (handle) do połączenia SSL
>>>> z możliwością sprawdzenia "odciska palca" klucza używanego przez serwer?
>>>>
>>>> Chce się łączyć z serwisem który używa samodzielnie generowanych kluczy
>>>
>>> Klucze zawsze są generowane przez stronę serwującą usługę. Mówisz
>>> o certyfikatach.
>>>
>>>> i sprawdzanie przez Certification Authority zawsze "padnie".
>>>
>>> Zawsze zawiedzie? Jeśli to certyfikaty tupu self-signed, to wystarczy
>>> dodać sam certyfikat do CAfile/CApath. Jeśli to certyfikaty wydane przez
>>> własne CA, to lepiej poproś o certyfikat tamtego CA.
>>
>> Ja jestem zainteresowany akceptowaniem tylko certyfikatu jednego serwera.
>
> To to się robi callbackiem oceniającym akceptowalność certyfikatu
> drugiej strony (tj. sprawdza poprawność atrybutu commonName). Co rzecz
> jasna zakłada zaufanie wobec certificate authority. Sorry, Winetou,
> that's the way X.509 works.

Mnie interesuje funkcjonalność którą oferuje *wiele* programów np. fetchmail.

-- 
Andrzej Adam Filip : anfi@onet.eu : Andrzej.Filip@gmail.com
Wielcy lunatycy nie potrzebują księżyca.
  -- Lec, Stanisław Jerzy (1909-1966)

Stachu 'Dozzie' K. wrote:
> To to się robi callbackiem oceniającym akceptowalność certyfikatu
> drugiej strony (tj. sprawdza poprawność atrybutu commonName).

Niekoniecznie tylko CN. Callback dostaje wskaźnik na wszystkie
certyfikaty ze ścieżki wysłane przez serwer, można więc sprawdzić co się
chce, nawet czy numer seryjny jest liczbą pierwszą.

> Sorry, Winetou, that's the way X.509 works.

Nie sądzę. To raczej kwestia niedopracowanych aplikacji, których autorzy
idąc po najmniejszej linii oporu, dają możliwość wyłącznie sprawdzania
ścieżki zaufania od podanego certyfikatu CA. Nie widzę powodów dla
których klient SSL/TLS nie mógłby weryfikować certyfikatów na podstawie
podanej listy ich fingerprintów, całej ich zawartości albo jeszcze
czegoś innego. Skoro PGP i SSH to potrafią, X.509 również powinno,
zwłaszcza, że sam protokół ani OpenSSL nie stoją tu na przeszkodzie.

Co do samego rozwiązania:

#v+
use strict;
use IO::Socket::SSL;
use Net::SSLeay;

my $client = new IO::Socket::SSL(
    PeerAddr => 'www.example.com',
    PeerPort => 443,
    SSL_verify_callback => sub {
      print Net::SSLeay::PEM_get_string_X509(Net::SSLeay::X509_STORE_CTX_get_current_cert($_[1]));
    });
#v-

Da Ci to string z połączonymi certyfikatami w formacie PEM zwróconymi przez
serwer. A z tym możesz już zrobić co chcesz.

Adam Osuchowski <someone@somewhere.com> pisze:

> Stachu 'Dozzie' K. wrote:
>> To to się robi callbackiem oceniającym akceptowalność certyfikatu
>> drugiej strony (tj. sprawdza poprawność atrybutu commonName).
>
> Niekoniecznie tylko CN. Callback dostaje wskaźnik na wszystkie
> certyfikaty ze ścieżki wysłane przez serwer, można więc sprawdzić co się
> chce, nawet czy numer seryjny jest liczbą pierwszą.
>
>> Sorry, Winetou, that's the way X.509 works.
>
> Nie sądzę. To raczej kwestia niedopracowanych aplikacji, których autorzy
> idąc po najmniejszej linii oporu, dają możliwość wyłącznie sprawdzania
> ścieżki zaufania od podanego certyfikatu CA. Nie widzę powodów dla
> których klient SSL/TLS nie mógłby weryfikować certyfikatów na podstawie
> podanej listy ich fingerprintów, całej ich zawartości albo jeszcze
> czegoś innego. Skoro PGP i SSH to potrafią, X.509 również powinno,
> zwłaszcza, że sam protokół ani OpenSSL nie stoją tu na przeszkodzie.
>
> Co do samego rozwiązania:
>
> #v+
> use strict;
> use IO::Socket::SSL;
> use Net::SSLeay;
>
> my $client = new IO::Socket::SSL(
>     PeerAddr => 'www.example.com',
>     PeerPort => 443,
>     SSL_verify_callback => sub {
>       print Net::SSLeay::PEM_get_string_X509(Net::SSLeay::X509_STORE_CTX_get_current_cert($_[1]));
>     });
> #v-
>
> Da Ci to string z połączonymi certyfikatami w formacie PEM zwróconymi przez
> serwer. A z tym możesz już zrobić co chcesz.

Dzięki - z tego da się już zrobić to o co mi chodzi.
W ramach upraszczania: czy da się to dostać w formacie binarnym?

-- 
Andrzej Adam Filip : anfi@onet.eu : Andrzej.Filip@gmail.com
Okno na świat można zasłonić gazetą.
  -- Lec, Stanisław Jerzy (1909-1966)

Andrzej Adam Filip wrote:
> W ramach upraszczania: czy da się to dostać w formacie binarnym?

No przecież to zwykły base64 jest, więc w czym problem?

#v+
use MIME::Base64;

my $certs = Net::SSLeay::PEM_get_string_X509(Net::SSLeay::X509_STORE_CTX_get_current_cert($_[1]));

while ($certs =~ m/-----BEGIN( CERTIFICATE-----)(.*?)-----END\1/sg) {
  print decode_base64($2);
}
#v-

Pewnie jest jakiś kolejny wysoce specjalizowany moduł na CPANie, którego
jedynym zadaniem jest konwersja PEM-to-DER, ale najszybciej to chyba
obrobić po prostu regexpem i MIME::Base64.