Re: [packages/openssl] - rel 2; disable unsecure protocols (zlib: CRIME attack; SSLv2: uses md5; SSLv3: POODLE) - enable en
arekm wrote: commit e02b6d37706201456a69b1fecd0e54304bb8d0f5 Author: Arkadiusz Miśkiewicz ar...@maven.pl Date: Mon Oct 20 19:45:36 2014 +0200 - rel 2; disable unsecure protocols (zlib: CRIME attack; SSLv2: uses md5; SSLv3: POODLE) - enable enable-ec_nistp_64_gcc_128 on x86_64 [...] + no-ssl2 \ + no-ssl3 \ Tak nie może być. To, że SSL2 i SSL3 są niebezpieczne nie oznacza, że należy od razu wywalić dla nich support. Te opcje usuwają również możliwość łączenia się z klienta s_client za pomocą SSL2/SSL3, a to jest potrzebne, chociażby po to, żeby sprawdzić czy dany serwis nie obsługuje przez przypadek SSL2/SSL3 (że nie wspomnę o tym, że część usług jeszcze chodzi na SSL3). Zresztą w przypadku serwera wywalanie tego też jest bez sensu, z analogicznych powodów. Ograniczanie dostępności protokołów powinno mieć miejsce na poziomie konfiguracji aplikacji, a nie fizycznym wywaleniu supportu z biblioteki. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [packages/openssl] - rel 2; disable unsecure protocols (zlib: CRIME attack; SSLv2: uses md5; SSLv3: POODLE) - enable en
On 21/10/14 13:58, Adam Osuchowski wrote: Tak nie może być. To, że SSL2 i SSL3 są niebezpieczne nie oznacza, że należy od razu wywalić dla nich support. Te opcje usuwają również możliwość łączenia się z klienta s_client za pomocą SSL2/SSL3, a to jest potrzebne, chociażby po to, żeby sprawdzić czy dany serwis nie obsługuje przez przypadek SSL2/SSL3 (że nie wspomnę o tym, że część usług jeszcze chodzi na SSL3). Zresztą w przypadku serwera wywalanie tego też jest bez sensu, z analogicznych powodów. Ograniczanie dostępności protokołów powinno mieć miejsce na poziomie konfiguracji aplikacji, a nie fizycznym wywaleniu supportu z biblioteki. +1 Też mi się ten commit nie podobał… powiedziałbym, że to wręcz szalony pomysł. Biblioteka powinna implementować wszystkie protokoły i szyfry jakie umie, konfiguracja klientów i serwerów (także ta za-hard-kodowana w nich) dopiero może to ograniczać. Jedyne co można by, ewentualnie, w openssl zmienić do domyślny wybór protokołów i szyfrów. Ale i to może być ryzykowne – jak potem wytłumaczyć klientowi fakt, że coś „działało, a już nie działa”. Pozdrawiam, Jajcuś ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [packages/openssl] - rel 2; disable unsecure protocols (zlib: CRIME attack; SSLv2: uses md5; SSLv3: POODLE) - enable en
On Tuesday 21 of October 2014, Adam Osuchowski wrote: arekm wrote: commit e02b6d37706201456a69b1fecd0e54304bb8d0f5 Author: Arkadiusz Miśkiewicz ar...@maven.pl Date: Mon Oct 20 19:45:36 2014 +0200 - rel 2; disable unsecure protocols (zlib: CRIME attack; SSLv2: uses md5; SSLv3: POODLE) - enable enable-ec_nistp_64_gcc_128 on x86_64 [...] + no-ssl2 \ + no-ssl3 \ Tak nie może być. To, że SSL2 i SSL3 są niebezpieczne nie oznacza, że należy od razu wywalić dla nich support. Co wcale nie oznacza, że należy ów support zostawiać. Te opcje usuwają również możliwość łączenia się z klienta s_client za pomocą SSL2/SSL3, a to jest potrzebne, chociażby po to, żeby sprawdzić czy dany serwis nie obsługuje przez przypadek SSL2/SSL3 (że nie wspomnę o tym, że część usług jeszcze chodzi na SSL3). Zresztą w przypadku serwera wywalanie tego też jest bez sensu, z analogicznych powodów. Ograniczanie dostępności protokołów powinno mieć miejsce na poziomie konfiguracji aplikacji, a nie fizycznym wywaleniu supportu z biblioteki. Jak zwykle kwestia dyskusyjna. Część aplikacji nie ma możliwości konfiguracji protokołów (np. wyszło przy okazji, że libghttp nawet nie korzystał z TLS tylko jechał na SSLv2). Debian np robi dokładnie w ten sposób - wyłącza na poziomie openssl tym samym 'wyłączając wszystkim aplikacjom. Od razu mówię, że nie upieram się na siłę. Jak zwykle w PLD, jak ktoś potrzebuje to się zostawia... więc istnieje możliwość powrotu do poprzedniej opcji. Pozdrawiam, -- Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org ) ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [packages/openssl] - rel 2; disable unsecure protocols (zlib: CRIME attack; SSLv2: uses md5; SSLv3: POODLE) - enable en
Arkadiusz Miśkiewicz wrote: Co wcale nie oznacza, że należy ów support zostawiać. Co najmniej psuje to w drastyczny sposób kompatybilność i stan obecny. Jak zwykle kwestia dyskusyjna. Część aplikacji nie ma możliwości konfiguracji protokołów (np. wyszło przy okazji, że libghttp nawet nie korzystał z TLS tylko jechał na SSLv2). IMHO to wina libghttp i jego by trzeba było spatchować zamiast openssla. Ktoś jeszcze zna jakieś takie pakiety, który zachowują się podobnie? BTW, jak taki soft nie używa w ogóle TLSa to po wywaleniu SSLi z openssla w ogóle przestanie działać. Debian np robi dokładnie w ten sposób - wyłącza na poziomie openssl tym samym 'wyłączając wszystkim aplikacjom. To, że debian robi zamordyzm nie oznacza, że PLD też musi. Podałem przykład gdzie to jest problematyczne (i mówie to z własnego doswiadczenia). Usunięcie supportu z klienta może dać złudną nadzieję, że serwer jest poprawnie skonfigurowany. Od razu mówię, że nie upieram się na siłę. Jak zwykle w PLD, jak ktoś potrzebuje to się zostawia... więc istnieje możliwość powrotu do poprzedniej opcji. To prosiłbym o przywrócenie poprzedniego stanu. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [packages/openssl] - rel 2; disable unsecure protocols (zlib: CRIME attack; SSLv2: uses md5; SSLv3: POODLE) - enable en
On 21.10.2014 14:09, Jacek Konieczny wrote: On 21/10/14 13:58, Adam Osuchowski wrote: Tak nie może być. To, że SSL2 i SSL3 są niebezpieczne nie oznacza, że należy od razu wywalić dla nich support. Te opcje usuwają również możliwość łączenia się z klienta s_client za pomocą SSL2/SSL3, a to jest potrzebne, chociażby po to, żeby sprawdzić czy dany serwis nie obsługuje przez przypadek SSL2/SSL3 (że nie wspomnę o tym, że część usług jeszcze chodzi na SSL3). Zresztą w przypadku serwera wywalanie tego też jest bez sensu, z analogicznych powodów. Ograniczanie dostępności protokołów powinno mieć miejsce na poziomie konfiguracji aplikacji, a nie fizycznym wywaleniu supportu z biblioteki. +1 Też mi się ten commit nie podobał… powiedziałbym, że to wręcz szalony pomysł. Biblioteka powinna implementować wszystkie protokoły i szyfry jakie umie, konfiguracja klientów i serwerów (także ta za-hard-kodowana w nich) dopiero może to ograniczać. Jedyne co można by, ewentualnie, w openssl zmienić do domyślny wybór protokołów i szyfrów. Ale i to może być ryzykowne – jak potem wytłumaczyć klientowi fakt, że coś „działało, a już nie działa”. Oooo to to to, i jeszcze - a inne serwisy nadal działają więc co mi pan tu p... Już kilka telefonów dziś miałem. BTW:IE7 i IE8 na XP nie działają z nowym opensslem... Tak wiem, stare itd itd ale nie mam wpływu na nie swoje komputery, a z Don Kichotem nie jestem. -- Andrzej Zawadzki ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [packages/openssl] - rel 2; disable unsecure protocols (zlib: CRIME attack; SSLv2: uses md5; SSLv3: POODLE) - enable en
On Tuesday 21 of October 2014, Adam Osuchowski wrote: Jak zwykle w PLD, jak ktoś potrzebuje to się zostawia... więc istnieje możliwość powrotu do poprzedniej opcji. To prosiłbym o przywrócenie poprzedniego stanu. Commituj, rw z tego co widzę masz. Teraz wystarcza przełączyć bcondy. Osobiście bym dał: zlib - wyłączone sslv2 - wyłączone sslv3 - włączone ps. mam tu jedno zgłoszenie o problemach z XP i IE7/8... o dziwo oba IE umieją TLS, a jednak są jakieś problemy po upgrade openssla ps2. do testowania publicznych serwisów https niezły jest: https://www.ssllabs.com/ssltest/analyze.html -- Arkadiusz Miśkiewicz, arekm / ( maven.pl | pld-linux.org ) ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [packages/openssl] - rel 2; disable unsecure protocols (zlib: CRIME attack; SSLv2: uses md5; SSLv3: POODLE) - enable en
Arkadiusz Miśkiewicz wrote: Commituj, rw z tego co widzę masz. Teraz wystarcza przełączyć bcondy. Ok. Osobiście bym dał: zlib - wyłączone sslv2 - wyłączone sslv3 - włączone Ja się SSL2 nie chcę pozbywać. On jest uznawany za niebezpieczny od dawna i do tej pory jakoś z tym żyliśmy, a jest potrzebny do tego samego co SSL3. Co do zliba to nie mam zdania. Komuś jest zlib potrzebny? Na razie przywróciłem domyślnie tak jak było. ps2. do testowania publicznych serwisów https niezły jest: https://www.ssllabs.com/ssltest/analyze.html Wiem, znam, ale po pierwsze, jak sam zauważyłeś jest tylko do publicznych serwisów, po drugie potrafi tylko skanować port 443 i bez starttlsa, po trzecie jest dość wolny bo sprawdza jeszcze wiele innych rzeczy (np. szyfry, itp.), po czwarte nie da się go oskryptować i robić testów wsadowo/okresowo. ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
Re: [packages/openssl] - rel 2; disable unsecure protocols (zlib: CRIME attack; SSLv2: uses md5; SSLv3: POODLE) - enable en
On Tue, Oct 21, 2014 at 14:13:49 +0200, Arkadiusz Miśkiewicz wrote: Tak nie może być. To, że SSL2 i SSL3 są niebezpieczne nie oznacza, że należy od razu wywalić dla nich support. Co wcale nie oznacza, że należy ów support zostawiać. To wywalić trzeba od razu PPTP (co tam jakieś MS CHAP-y i inne dziadostwa windowsowe trzymać dziurawe), WEP-a, MD5, wszystkie w ogóle słabe szyfry, HTTP nieszyfrowane, i co tam - SMTP też do piachu. Prawidłowe rozwiązanie to dostarczenie domyślnej konfiguracji, w której tego typu niebezpieczne rozwiązania są wyłączone, ale można je na własne życzenie włączyć. Bo jak nie to zaraz ktoś wyłączy bcondy LDAP czy Kerberosowe, bo tam też na pewno były i są jakieś secbłędy w kodzie. Wszystko inne to tworzenie iluzji, że PLD jest bezpieczne. -- Tomasz Pala go...@pld-linux.org ___ pld-devel-pl mailing list pld-devel-pl@lists.pld-linux.org http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
