15
Mam sytuację, w której klient wykonuje wywołanie przez zwinięcie do adresu URL https. Certyfikat SSL adresu URL protokołu https jest samopodpisany, dlatego funkcja zwijania nie może przeprowadzić sprawdzania poprawności certyfikatu i kończy się niepowodzeniem. curl udostępnia opcję -k/- insurec, która wyłącza sprawdzanie poprawności certyfikatu. Moje pytanie jest takie, że przy użyciu opcji --insecure przesyłanie danych odbywa się między klientem a serwerem zaszyfrowanym (tak jak powinno być w przypadku adresów URL https)? Rozumiem ryzyko bezpieczeństwa z powodu nieudanego sprawdzania poprawności certyfikatu, ale w przypadku tego pytania niepokoi mnie tylko to, czy transfer danych jest szyfrowany, czy nie.Niepewna blokada opcji
bardzo złą strategią; patrz [Najbardziej niebezpieczny kod na świecie: sprawdzanie poprawności certyfikatów SSL w oprogramowaniu nie przeglądarkowym] (http://crypto.stanford.edu/~dabo/pubs/abstracts/ssl-client-bugs.html). – jww
@jww, niekoniecznie złe, jeśli znajdujesz się w sytuacji, w której nie kontrolujesz używanych certyfikatów (w tym przypadku z autopodpisaniem), ale nadal masz potrzebę testowania za pomocą zwijania. Zgadzam się, że używanie samopodpisanych certyfikatów bez instalowania łańcucha CA (tak jak w środowisku korporacyjnym) jest złym pomysłem, ale w dużych organizacjach często nie ma kontroli nad osobą, która pisze jakiś kod lub za pomocą interfejsu API. – ntwrkguru