Sprawdzanie ważności certyfikatu

[Gość]

Domyślnie Firefox ma wyłączoną funkcję sprawdzania ważności certyfikatu stron internetowych: Opcje/Zaawansowane/Bezpieczeństwo/Weryfikacja.
Jakie ustawienie gwarantuje sprawdzanie ważności certyfikatu? Proszę o rzeczową odpowiedź.

Nie muszę chyba dodawać, jak ważna jest to kwestia dla bezpieczeństwa użytkowników. Dziwi więc nieco domyślne wyłączenie tej funkcjonalności.

Dla zainteresowanych na planet.mozillapl.org artykuł z blogu Roberta Błauta na ten temat.

[carlos]

Domyślnie Firefox ma wyłączoną funkcję sprawdzania ważności certyfikatu stron internetowych: Opcje/Zaawansowane/Bezpieczeństwo/Weryfikacja.
Jakie ustawienie gwarantuje sprawdzanie ważności certyfikatu? Proszę o rzeczową odpowiedź.

Import list CRL od znanych CA lub włączenie OSCP.

Nie muszę chyba dodawać, jak ważna jest to kwestia dla bezpieczeństwa użytkowników. Dziwi więc nieco domyślne wyłączenie tej funkcjonalności.

Nie jest aż tak ważna, jakby się mogło wydawać. Poznając X.509 PKI też mi się tak wydawało, a tu proszę, system działa od lat 90-tych i świat jakoś się nie zawalił W razie problemów z cerytfikatem dostępny będzie update ze strony mozilli/microsoft/etc.

Dla zainteresowanych na planet.mozillapl.org artykuł z blogu Roberta Błauta na ten temat.

Przeczytałem, ale odniosłem wrażenie, że pan Robert ma niewielkią więdzę na temat, który opisuje (albo chce, żeby tak wyglądało). Bez urazy oczywiście.

Pozdrawiam.

[quiris]

Przeczytałem, ale odniosłem wrażenie, że pan Robert ma niewielkią więdzę na temat, który opisuje (albo chce, żeby tak wyglądało). Bez urazy oczywiście.

Czy w takim razie mógłbym prosić o wyjaśnienia eksperta? Na naukę nigdy za późno.

[carlos]

Postaram się jakoś w skrócie to ująć, tylko nie wiem czy pisać o tekście z blogu czy o OSCP...

Jeśli chodzi o "ważność" certyfikatów: certyfikaty wystawiane są na pewien czas i ta ważność jest sprawdzana (po upływie terminu ważności domyślnie pojawia się okno z zapytaniem). OSCP służy do sprawdzenia 'online', czy dany certyfikat nie został unieważniony (przez podmiot, który go wystawił) przed upływem terminu ważności. W klasycznej X.509 PKI w tym celu używa się list CRL, publikowanych przez centra certyfikacyjne.

Teraz, przy podejściu "akademickim" jasne jest, że bez list CRL i/lub OSCP cały system nie ma sensu. To teoria. W praktyce okazuje się, że ma się całkiem dobrze. Czemu tak jest, to już spekulacje na temat stanu rynku... W każdym bądź razie, znam jeden przypadek "z życia", gdy centrum certyfikacji musiało wycofać wydany wcześniej certyfikat (Verisign wystawiło certyfikat na nazwę "Microsoft" dla osoby nie związanej z tą firmą; dobra analiza, niestety po angielsku).

Jeśli chodzi o listy CRL, zostały one zaprojektowane do weryfikacji 'offline' i problemem w dzisiejszej komunikacji internetowej jest ilość ruchu, jaki jest generowany przez klientów. (np. znów Verisign: http://it.slashdot.org/article.pl?sid=04/01/08/1849245)

Z drugiej strony mamy OSCP, zaprojektowany później jako protokół 'online', minimalizuje ruch ale dodaje dodatkowy "punkt krytyczny" - o ile listy CRL są podpisane przez centrum CA, które je wystawiło, kluczem który jest nam znany (przeglądarce) i sama lista może być pobrana z dowolnego miejsca, to w przypadku OSCP musisz zaufać kolejnemu serwerowi... Co stawia pytanie: co powoduje, że ufasz CA A jeśli nawet miałyby to być serwery CA... cóż, nie wszyskie centra obsługują ten protokół...

Czy taka sytuacja jest dobra? Oczywiście nie i, o ile się orientuję, prowadzone są prace w mozilli nad przynajmniej częściowym jej uporządkowaniem (domyślnie instalowane certyfikaty w przeglądarce, listy CRL, serwery OSCP, itp.):
http://www.hecker.org/mozilla/ca-certificate-list
http://www.mozilla.org/projects/securit ... olicy.html

Jeśli chodzi o tekst z blogu to, krótko, bo późno się zrobiło, za dużo tam założeń i niedopowiedzeń. Nie wiem, czy to winika z niewiedzy, braku doświadczenia czy po prostu z góry założonej linii (opera...), ale tak to widzę. Np. po przeczytaniu go, problem unieważnionych certyfikatów przed upływem ich terminu ważności wydaje się ogromny, OSCP wydaje się magicznym kluczem na wszystkie problemy, gdzie tak na prawdę *pewne* problemy zastępowane są innymi, a zupełnie pominięte są dużo problemy dużo bardziej prawdopodobne (SSL2? szyfrowanie z małym kluczem? błędy przeglądarek, systemów? itp...)

Mam nadzieję, że nikogo nie uraziłem poprzednim postem

Pozdrawiam.

[carlos]

Żeby nie wyszło, że tylko narzekam:

Jeśli ktoś chciałby spróbować protokołu OCSP:
Narzędzia -> Opcje -> Zaawansowane -> Bezpieczeństwo -> Weryfikacja -> "Weryfikuj tylko certyfikaty zawierające adres URL usługi OCSP"

W ten sposób, jeśli wystawca certyfikatu (CA) dołączył adres swojego serwera OCSP firefox przeprowadzi weryfikację.

Tak z ciekawości sprawdziłem - certyfikaty mbanku, intelligo i kilku jeszcze banków najczęściej są wystawione przez Verisign/Thawte i mają podane obie usługi (CRL i OCSP).

Pozdrawiam.

[quiris]

Postaram się jakoś w skrócie to ująć, tylko nie wiem czy pisać o tekście z blogu czy o OSCP...

Oczywiście rozmawiamy o OCSP, a nie o OSCyPku

Jeśli chodzi o "ważność" certyfikatów: certyfikaty wystawiane są na pewien czas i ta ważność jest sprawdzana (po upływie terminu ważności domyślnie pojawia się okno z zapytaniem). OSCP służy do sprawdzenia 'online', czy dany certyfikat nie został unieważniony (przez podmiot, który go wystawił) przed upływem terminu ważności.

No tak, to jest powszechnie wiadome (pisałem o tym w omawianym blogu) i jest to podstawowa zaleta OCSP.

Teraz, przy podejściu "akademickim" jasne jest, że bez list CRL i/lub OSCP cały system nie ma sensu. To teoria. W praktyce okazuje się, że ma się całkiem dobrze. Czemu tak jest, to już spekulacje na temat stanu rynku... W każdym bądź razie, znam jeden przypadek "z życia", gdy centrum certyfikacji musiało wycofać wydany wcześniej certyfikat (Verisign wystawiło certyfikat na nazwę "Microsoft" dla osoby nie związanej z tą firmą; dobra analiza, niestety po angielsku).

A co powiesz na sytuację związaną z systemem enbepe obsługującym konta budżetowe: http://serwis.enbepe.pl Przecież niemalże codziennie słyszy się, że jakiś urzędnik traci pracę i jeśli miał prawo podpisywania dokumentów finansowych kartą z prywatnym kluczem, to jemu należy certyfikat niezwłocznie unieważnić, czyli praktycznie codziennie należałoby ściągać listę CRL, czego oczywiście nie robi się z uwagi na upierdliwość operacji, czego nazwać bezpiecznym nie mogę OCSP rozwiązałoby ten problem, gdyby w omawianym oprogramowaniu było zaimplementowane.

Z drugiej strony mamy OSCP, zaprojektowany później jako protokół 'online', minimalizuje ruch ale dodaje dodatkowy "punkt krytyczny" - o ile listy CRL są podpisane przez centrum CA, które je wystawiło, kluczem który jest nam znany (przeglądarce) i sama lista może być pobrana z dowolnego miejsca, to w przypadku OSCP musisz zaufać kolejnemu serwerowi...

Muszę mniej więcej w takim samym stopniu ufać temu serwerowi, jak temu z którego pobieram listę CRL

Jeśli chodzi o tekst z blogu to, krótko, bo późno się zrobiło, za dużo tam założeń i niedopowiedzeń. Nie wiem, czy to winika z niewiedzy, braku doświadczenia czy po prostu z góry założonej linii (opera...), ale tak to widzę.

Wpis w blogu z założenia nie jest rozprawą doktorską. Swoim tekstem chciałem tylko zwrócić w możliwie prostych słowach zwyczajnym użytkownikom uwagę na fakt istnienia potencjalnego niebezpieczeństwa korzystania z instytucji finasowych on-line i przy okazji zwrócić uwagę na zaimplementowane w przeglądarkach nowe metody ograniczania niebezpieczeństwa przechwycenia poufnych danych, a które to metody nie są niestety domyślnie wyłączone w najpopularniejszych przeglądarkach. Nie przeczę, że przy okazji z dużą satysfakcją odnotowałem fakt włączenia OCSP w Operze. Zwracam równocześnie uwagę, że działanie OCSP w Operze 8.54 jest niezwykle drakońskie, czego negatywne skutki zdążyli już odczuć użytkownicy tej przeglądarki i będący klientami niektórych polskich banków. Wygląda to tak, że jeśli Opera nie może połączyć się z serwerem OSCP i zweryfikować certyfikatu, połączenie szyfrowane zostaje odrzucone, a na stronie pojawia się komunikat o błędzie. Szczegóły w http://operapl.net/faq/#304 Opisane problemy były spowodowane awarią serwerów OCSP po stronie CA. Zdarzenia są opisane w wątkach http://my.opera.com/community/forums/to ... ?id=131747 oraz http://my.opera.com/community/forums/to ... ?id=138010

Np. po przeczytaniu go, problem unieważnionych certyfikatów przed upływem ich terminu ważności wydaje się ogromny, OSCP wydaje się magicznym kluczem na wszystkie problemy, gdzie tak na prawdę *pewne* problemy zastępowane są innymi, a zupełnie pominięte są dużo problemy dużo bardziej prawdopodobne (SSL2? szyfrowanie z małym kluczem? błędy przeglądarek, systemów? itp...)

Jeśli odniosłeś takie wrażenie, to przepraszam, ale nie było ono celem tego co napisałem. Zdaję sobie sprawę z tego, że OCSP nie jest „lekiem na całe zło”, ale jeśli choć trochę pomaga zwiększyć nasze bezpieczeństwo, to należy to promować

Mam nadzieję, że nikogo nie uraziłem poprzednim postem

Nie ma problemu. Zdaję sobie sprawę, że na pewno mam mniejszą wiedzę na te tematy niż ty.

Tak z ciekawości sprawdziłem - certyfikaty mbanku, intelligo i kilku jeszcze banków najczęściej są wystawione przez Verisign/Thawte i mają podane obie usługi (CRL i OCSP).

Uhm. Podtwierdzam. Użytkownicy Opery będący klientami Inteligo zdążyli poznać na własnej skórze efekt niedziałania OCSP. W Operze 9, której premiera przewidziana jest w tym miesiącu, zmieniono to drakońskie zachowanie. W podobnej sytuacji będzie po prostu obniżany poziom bezpieczeństwa danej strony jaki Opera sygnalizuje użytkownikowi, sugerując, że nie jest do końca wszystko w porządku z tą stroną.

[carlos]

Postaram się jakoś w skrócie to ująć, tylko nie wiem czy pisać o tekście z blogu czy o OSCP...

Oczywiście rozmawiamy o OCSP, a nie o OSCyPku

Ach... OK

Jeśli chodzi o "ważność" certyfikatów: certyfikaty wystawiane są na pewien czas i ta ważność jest sprawdzana (po upływie terminu ważności domyślnie pojawia się okno z zapytaniem). OSCP służy do sprawdzenia 'online', czy dany certyfikat nie został unieważniony (przez podmiot, który go wystawił) przed upływem terminu ważności.

No tak, to jest powszechnie wiadome (pisałem o tym w omawianym blogu) i jest to podstawowa zaleta OCSP.

OK, ale ani o wadach ani o zaletach nic nie piszesz Hej, właśnie sobie zdałem sprawę, że Ty jesteś autorem tego tekstu...

Teraz, przy podejściu "akademickim" jasne jest, że bez list CRL i/lub OSCP cały system nie ma sensu. To teoria. W praktyce okazuje się, że ma się całkiem dobrze. Czemu tak jest, to już spekulacje na temat stanu rynku... W każdym bądź razie, znam jeden przypadek "z życia", gdy centrum certyfikacji musiało wycofać wydany wcześniej certyfikat (Verisign wystawiło certyfikat na nazwę "Microsoft" dla osoby nie związanej z tą firmą; dobra analiza, niestety po angielsku).

A co powiesz na sytuację związaną z systemem enbepe obsługującym konta budżetowe: http://serwis.enbepe.pl Przecież niemalże codziennie słyszy się, że jakiś urzędnik traci pracę i jeśli miał prawo podpisywania dokumentów finansowych kartą z prywatnym kluczem, to jemu należy certyfikat niezwłocznie unieważnić, czyli praktycznie codziennie należałoby ściągać listę CRL, czego oczywiście nie robi się z uwagi na upierdliwość operacji, czego nazwać bezpiecznym nie mogę OCSP rozwiązałoby ten problem, gdyby w omawianym oprogramowaniu było zaimplementowane.

Na początek - wcześniejsze rozważania dotyczyły przeglądarek i certyfikatów wystawianych serwerom publicznym na potrzeby SSL/TLS. Jeśli chodzi zamknięte systemy - tu można narzucić użytkownikom bardziej restrykcyjne reguły. Co do enbepe.pl - nie wiem, nie znam go, ale nawet na stronie, którą podałeś jest link do listy CRL (administrator systemu powinien zadbać o jej dystrybucję). Po zaimportowaniu do programu (przeglądarki, czy czego tam używają), program powinien ją uaktualniać co jakiś czas automatycznie (przeglądarki mają tę funkcję).

Z drugiej strony mamy OSCP, zaprojektowany później jako protokół 'online', minimalizuje ruch ale dodaje dodatkowy "punkt krytyczny" - o ile listy CRL są podpisane przez centrum CA, które je wystawiło, kluczem który jest nam znany (przeglądarce) i sama lista może być pobrana z dowolnego miejsca, to w przypadku OSCP musisz zaufać kolejnemu serwerowi...

Muszę mniej więcej w takim samym stopniu ufać temu serwerowi, jak temu z którego pobieram listę CRL

A widzisz, nie. Listy CRL możesz pobrać z dowolnego źródła. Nawet od osoby, której nie ufasz.
To jest ta własność CRL, której nie ma OCSP.

Jeśli chodzi o tekst z blogu to, krótko, bo późno się zrobiło, za dużo tam założeń i niedopowiedzeń. Nie wiem, czy to winika z niewiedzy, braku doświadczenia czy po prostu z góry założonej linii (opera...), ale tak to widzę.

Wpis w blogu z założenia nie jest rozprawą doktorską. Swoim tekstem chciałem tylko zwrócić w możliwie prostych słowach zwyczajnym użytkownikom uwagę na fakt istnienia potencjalnego niebezpieczeństwa korzystania z instytucji finasowych on-line i przy okazji zwrócić uwagę na zaimplementowane w przeglądarkach nowe metody ograniczania niebezpieczeństwa przechwycenia poufnych danych, a które to metody nie są niestety domyślnie wyłączone w najpopularniejszych przeglądarkach. Nie przeczę, że przy okazji z dużą satysfakcją odnotowałem fakt włączenia OCSP w Operze. Zwracam równocześnie uwagę, że działanie OCSP w Operze 8.54 jest niezwykle drakońskie, czego negatywne skutki zdążyli już odczuć użytkownicy tej przeglądarki i będący klientami niektórych polskich banków. Wygląda to tak, że jeśli Opera nie może połączyć się z serwerem OSCP i zweryfikować certyfikatu, połączenie szyfrowane zostaje odrzucone, a na stronie pojawia się komunikat o błędzie. Szczegóły w http://operapl.net/faq/#304 Opisane problemy były spowodowane awarią serwerów OCSP po stronie CA. Zdarzenia są opisane w wątkach http://my.opera.com/community/forums/to ... ?id=131747 oraz http://my.opera.com/community/forums/to ... ?id=138010

O tym poniżej. Krótko tylko o odrzuceniu połączenia - to prawidłowa reakcja OCSP! Był on zaprojektowany jako protokół 'online' i jeśli nie jest w stanie stwierdzić, czy dany certyfikat jest poprawny, odrzuca go. Protokołem 'offline' jest użycie list CRL. Jak rozumiem twórcy Opery na życzenie użytkowników zmieniają zachowanie systemu kosztem poziomu bezpieczeństwa (nie tylko oni, tak to jest zazwyczaj...)

Np. po przeczytaniu go, problem unieważnionych certyfikatów przed upływem ich terminu ważności wydaje się ogromny, OSCP wydaje się magicznym kluczem na wszystkie problemy, gdzie tak na prawdę *pewne* problemy zastępowane są innymi, a zupełnie pominięte są dużo problemy dużo bardziej prawdopodobne (SSL2? szyfrowanie z małym kluczem? błędy przeglądarek, systemów? itp...)

Jeśli odniosłeś takie wrażenie, to przepraszam, ale nie było ono celem tego co napisałem. Zdaję sobie sprawę z tego, że OCSP nie jest „lekiem na całe zło”, ale jeśli choć trochę pomaga zwiększyć nasze bezpieczeństwo, to należy to promować

Mam nadzieję, że nikogo nie uraziłem poprzednim postem

Nie ma problemu. Zdaję sobie sprawę, że na pewno mam mniejszą wiedzę na te tematy niż ty.

Nie, nie o to chodzi. Po prostu tekst wydał mi się "ukierunkowany", a i jakiś gorszy dzień miałem. Ja też przepraszam, trochę się rozpędziłem.

Tak z ciekawości sprawdziłem - certyfikaty mbanku, intelligo i kilku jeszcze banków najczęściej są wystawione przez Verisign/Thawte i mają podane obie usługi (CRL i OCSP).

Uhm. Podtwierdzam. Użytkownicy Opery będący klientami Inteligo zdążyli poznać na własnej skórze efekt niedziałania OCSP. W Operze 9, której premiera przewidziana jest w tym miesiącu, zmieniono to drakońskie zachowanie. W podobnej sytuacji będzie po prostu obniżany poziom bezpieczeństwa danej strony jaki Opera sygnalizuje użytkownikowi, sugerując, że nie jest do końca wszystko w porządku z tą stroną.

Właśnie o to mi chodziło: część użytkowników może pomyśleć: "Firefoks nie sprawdza ważności certyfikatów przez OCSP, Opera tak więc jest bardziej bezpieczna". Nie będą zdawać sobie sprawy, że aby OCSP działało:
1. CA musi udostępnić tą usługę,
2. certyfikat musi posiadać informację, gdzie jest ta usługa (nie jestem pewien, czy przeglądarki potrafią znaleźć ją w inny sposób; stawiałbym, że nie),
3. usługa musi być dostępna w momencie sprawdzania certyfikatu. Co się stanie jeśli któryś z tych punktów nie będzie spełniony?

ad1. Opera nie użyje OCSP, bo go po prostu nie ma (użytkownik myśli, że wszystko jest OK!)
ad2. patrz ad1.
ad3. Opera 8.54, jak piszesz, odmówi dostępu do strony (prawidłowo), Opera 9 pokaże jakiś komunikat (uhh... jak rozumiem, wymagania "realnego" świata [biznes, użytkonicy, itp.])

Daje trochę złudne poczucie bezpieczeństwa, nie uważasz?

Na koniec, tak, należy promować używanie OCSP (czy CRLi, gdzie to bardziej dostępne/wymagane), ale należałoby wyjaśnić jakie są plusy i jakie ograniczenia... Np. w pierwszym poście gość, zadając pytanie "Jakie ustawienie gwarantuje sprawdzanie ważności certyfikatu?" wydaje się nie zdawać sprawy, że Opera (czy inna przeglądarka) nie sprawdza wszystkich certyfikatów. Dalej pisząc "Nie muszę chyba dodawać, jak ważna jest to kwestia dla bezpieczeństwa użytkowników. Dziwi więc nieco domyślne wyłączenie tej funkcjonalności" sieje jedynie popłoch wśród innych użytkowników. Ani nie jest to "aż tak ważne", ani rozpowszechnione wśród ośrodków CA, żeby nie mogło poczekać jeszcze trochę

Tak czy inaczej, zgadzam się, że kwestia sprawdzania certyfikatów powinna być rozwiązana (przez jej implementację i domyślne włączenie w przeglądarkach i nnym oprogramowaniu).

Pozdrawiam.

[quiris]

OK, ale ani o wadach ani o zaletach nic nie piszesz

Bo to nie był tekst o wadach i zaletach OCSP, ale o bezpieczeństwie w kontekście kryminalnego zdarzenia.

Hej, właśnie sobie zdałem sprawę, że Ty jesteś autorem tego tekstu...

Lepiej późno, niż wcale

Na początek - wcześniejsze rozważania dotyczyły przeglądarek i certyfikatów wystawianych serwerom publicznym na potrzeby SSL/TLS.

Fakt.

Co do enbepe.pl - nie wiem, nie znam go, ale nawet na stronie, którą podałeś jest link do listy CRL (administrator systemu powinien zadbać o jej dystrybucję). Po zaimportowaniu do programu (przeglądarki, czy czego tam używają), program powinien ją uaktualniać co jakiś czas automatycznie (przeglądarki mają tę funkcję).

Zapewniam cię, że trzeba to robić za każdym razem ręcznie. Tragedia

A widzisz, nie. Listy CRL możesz pobrać z dowolnego źródła. Nawet od osoby, której nie ufasz.
To jest ta własność CRL, której nie ma OCSP.

To, że CRL można pobrać z dowolnego źródła, bo jest podpisana przez CA, zgadzam się i zgadzam się również z tym, że odpowiedź OCSP nie może pochodzić z dowolnego źródła. Natomiast nie mogę zgodzić się, z pewną niebezpieczną konkluzją wynikającą z powyższego twojego stwierdzenia, że jakoby odpowiedź z serwera OCSP nie była bezpieczna. Otóż nie. Odpowiedź z serwera OCSP musi cechować się identycznym stopniem wiarygodności, jak list CRL, inaczej cały OCSP nie miałby żadnego merytorycznego uzasadnienia. Cytat z http://www.ietf.org/rfc/rfc2560.txt:

All definitive response messages SHALL be digitally signed. The key
used to sign the response MUST belong to one of the following:

-- the CA who issued the certificate in question
-- a Trusted Responder whose public key is trusted by the requester
-- a CA Designated Responder (Authorized Responder) who holds a
specially marked certificate issued directly by the CA, indicating
that the responder may issue OCSP responses for that CA

Właśnie o to mi chodziło: część użytkowników może pomyśleć: "Firefoks nie sprawdza ważności certyfikatów przez OCSP, Opera tak więc jest bardziej bezpieczna". Nie będą zdawać sobie sprawy, że aby OCSP działało:
1. CA musi udostępnić tą usługę,

Oczywiście

2. certyfikat musi posiadać informację, gdzie jest ta usługa (nie jestem pewien, czy przeglądarki potrafią znaleźć ją w inny sposób; stawiałbym, że nie),

Zgodnie z wymienionym wyżej RFC przeglądarka może mieć wbudowaną listę OCSP responderów:

Alternatively, the accessLocation for the OCSP provider may be configured locally at the OCSP client.

3. usługa musi być dostępna w momencie sprawdzania certyfikatu. Co się stanie jeśli któryś z tych punktów nie będzie spełniony?
ad1. Opera nie użyje OCSP, bo go po prostu nie ma (użytkownik myśli, że wszystko jest OK!)
ad2. patrz ad1.
ad3. Opera 8.54, jak piszesz, odmówi dostępu do strony (prawidłowo), Opera 9 pokaże jakiś komunikat (uhh... jak rozumiem, wymagania "realnego" świata [biznes, użytkonicy, itp.])

Odpowiadając na powyższe stwierdzić należy, że Opera 9 wyswietlając informację w pasku adresu o zabezpieczeniach obniży poziom bezpieczeństwa i jednocześnie zmieni wygląd paska z żółtego na szary. W szczegółach informacji opisane są problemy jakie zostały zauważone. Użytkownik zostanie ostrzeżony o problemach i sam musi zdecydować, czy kontynuować pracę na takiej stronie: http://my.opera.com/yngve/blog/show.dml/257410

[carlos]

OK, ale ani o wadach ani o zaletach nic nie piszesz

Bo to nie był tekst o wadach i zaletach OCSP, ale o bezpieczeństwie w kontekście kryminalnego zdarzenia.

Tyle, że OCSP (ani CRL) nie ma z tymi wydarzeniami nic wspólnego i nie dają nic w tym kontekście. Zaryzykowałbym nawet stwierdzenie, że w przypadku publicznych serwerów zysk z wykorzystania OCSP/CRL jest żaden *w praktyce*.

To tak jakby powiedzieć: "Ostatnie raporty podają, że w poprzednim roku ofiarą kieszonkowców padło 100tyś osób. Przy tej okazji, jak sprawdziliśmy, tylko drzwi firmy X oferują zabezpieczenie przed strzałem z pocisku kalibru do 90mm". Oczywiście informacja o drzwiach jest zupełnie bez znaczenia w przypadku kieszonkowców. Pomijając, że do domu można dostać się przez okno, ryzyko strzału z takiego pocisku po to, by się dostać do domu jest...

Co do enbepe.pl - nie wiem, nie znam go, ale nawet na stronie, którą podałeś jest link do listy CRL (administrator systemu powinien zadbać o jej dystrybucję). Po zaimportowaniu do programu (przeglądarki, czy czego tam używają), program powinien ją uaktualniać co jakiś czas automatycznie (przeglądarki mają tę funkcję).

Zapewniam cię, że trzeba to robić za każdym razem ręcznie. Tragedia

Nie zazdroszę zatem, ale nie jest to wina X.509/CRL, tylko oprogramowania, które ich używa.

A widzisz, nie. Listy CRL możesz pobrać z dowolnego źródła. Nawet od osoby, której nie ufasz.
To jest ta własność CRL, której nie ma OCSP.

To, że CRL można pobrać z dowolnego źródła, bo jest podpisana przez CA, zgadzam się i zgadzam się również z tym, że odpowiedź OCSP nie może pochodzić z dowolnego źródła. Natomiast nie mogę zgodzić się, z pewną niebezpieczną konkluzją wynikającą z powyższego twojego stwierdzenia, że jakoby odpowiedź z serwera OCSP nie była bezpieczna. Otóż nie. Odpowiedź z serwera OCSP musi cechować się identycznym stopniem wiarygodności, jak list CRL, inaczej cały OCSP nie miałby żadnego merytorycznego uzasadnienia. Cytat z http://www.ietf.org/rfc/rfc2560.txt:

All definitive response messages SHALL be digitally signed. The key
used to sign the response MUST belong to one of the following:

-- the CA who issued the certificate in question
-- a Trusted Responder whose public key is trusted by the requester
-- a CA Designated Responder (Authorized Responder) who holds a
specially marked certificate issued directly by the CA, indicating
that the responder may issue OCSP responses for that CA

Nigdzie nie napisałem, by odpowiedź z serwera OCSP "nie była bezpieczna". Problem leży nie w "bezpieczeństwie" samej transakcji (musi być podpisana), ale w tym komu ufasz, by taką transakcję przeprowadził. W przypadku punktu 1 i 3 (z cytowanego fragmentu rfc) jest to jasne, ale co z drugim? Daje pole do popisu atakującemu (np. okienko: "Aby sprawdzić wiarygodność tej strony dodaj certyfikat centrum 'super-bezpieczne CA' do zaufanych. [OK] [Cancel]" <- które kliknie użytkownik? ) Generalnie, tam gdzie pojawia się podmiot 'Trusted' powinno zapalić się żółte światełko...

Ale, ale. OCSP poprawnie wykorzystany może działać, temu nie przeczę. Problem, tak jak w przypadku każdej innej technologii związanej z kryptografią, leży w edukacji użytkowników. W ich świadomym używaniu tych technologii.

Tak myślę, że co do teoretycznej strony się zgadzamy, ale to co nas różni to podejście do praktyki. Ja mówię: "To niewiele/nic nie daje oprócz fałszywego poczucia bezpieczeństwa, które jest gorsze od świadomego wyboru. Poza tym, jest wiele łatwiejszych metod na oszukanie użytkownika", Ty z kolei: "potencjalnie to daje dużo, jedynie Opera tego używa - jest bezpieczniejsza".

Kwestia preferencji jak sądzę...

Właśnie o to mi chodziło: część użytkowników może pomyśleć: "Firefoks nie sprawdza ważności certyfikatów przez OCSP, Opera tak więc jest bardziej bezpieczna". Nie będą zdawać sobie sprawy, że aby OCSP działało:
1. CA musi udostępnić tą usługę,

Oczywiście

Dla Ciebie czy dla mnie to oczywiste, ale dla osoby niezorientowanej już nie. Napisałem o tym, bo czytają post "gościa" widać, że nie jest tego świadomy. Chce mieć włączone "sprawdzanie ważności certyfikatu" jak w Operze, bo "nie musi chyba dodawać, jak ważna jest to kwestia dla bezpieczeństwa użytkowników". I zadaje pytanie, po którym widać już, że nie ma bladego pojęcia o czym pisze, a zainspirowany był treścią tekstu na blogu: "Jakie ustawienie gwarantuje sprawdzanie ważności certyfikatu?". Problem w tym, że (w ogólnym wypadku) żadne.

2. certyfikat musi posiadać informację, gdzie jest ta usługa (nie jestem pewien, czy przeglądarki potrafią znaleźć ją w inny sposób; stawiałbym, że nie),

Zgodnie z wymienionym wyżej RFC przeglądarka może mieć wbudowaną listę OCSP responderów:

Alternatively, the accessLocation for the OCSP provider may be configured locally at the OCSP client.

Ale pytanie było postawione "czy mają?" Pytanie na wpół retoryczne, sprawdzę w wolnej chwili. Ale listy CRL też mogą mieć wbudowane. Mają?

3. usługa musi być dostępna w momencie sprawdzania certyfikatu. Co się stanie jeśli któryś z tych punktów nie będzie spełniony?
ad1. Opera nie użyje OCSP, bo go po prostu nie ma (użytkownik myśli, że wszystko jest OK!)
ad2. patrz ad1.
ad3. Opera 8.54, jak piszesz, odmówi dostępu do strony (prawidłowo), Opera 9 pokaże jakiś komunikat (uhh... jak rozumiem, wymagania "realnego" świata [biznes, użytkonicy, itp.])

Odpowiadając na powyższe stwierdzić należy, że Opera 9 wyswietlając informację w pasku adresu o zabezpieczeniach obniży poziom bezpieczeństwa i jednocześnie zmieni wygląd paska z żółtego na szary. W szczegółach informacji opisane są problemy jakie zostały zauważone. Użytkownik zostanie ostrzeżony o problemach i sam musi zdecydować, czy kontynuować pracę na takiej stronie: http://my.opera.com/yngve/blog/show.dml/257410

OK. Dzięki za link. Pozostawię bez komentarza (musiałbym się powtórzyć ). Przy okazji, jak widzę, Opera rezygnuje z SSL2 i słabych algorytmów

Pozdrawiam.

[jacuś]

Panowie szlag mnie trafia bo w FF nie mogę teraz otworzyć prawie żadnej strony , a nawet zainstalować dodatków , bo jak twierdzi / błąd certyfikatów/
Nawet stron Mozilla org ani takich z których korzystałem i są bezpieczne. Strasznie popitolili to w wersji 44 nie można nawet dodać wyjątków.
Pora zmienić przeglądarkę bo psuja coraz bardziej.
chyba ze da się to jakoś wyłączyć

[dexter]

Powodem tej sytuacji jest Pana antywirus. Proszę przejrzeć 100 ostatnich tematów w tym dziale, wśród nich znajdzie Pan co najmniej 10 tematów z tym problemem, wraz z rozwiązaniami.