Podsumowanie dotyczące bezpieczeństwa w czerwcu 2020 r

Witamy w czerwcowym wydaniu podsumowania bezpieczeństwa SSL.com. Nadeszło lato, pandemia trwa, podobnie jak wiadomości o bezpieczeństwie cyfrowym! W tym miesiącu przyjrzymy się:

Jeśli szukasz certyfikatu SSL /TLS certyfikat dla swojej witryny, spójrz na przystępną cenowo, wysoką wartość SSL.com Opcje.

Senat rozważy wymagane backdoory szyfrowania

Ten jest trochę jak yikes-y. Podczas gdy wiele krajów rozważa zmniejszenie uprawnień organów ścigania, trzech senatorów wprowadziło Rachunek drakoński to zmusi firmy technologiczne do stworzenia schematu szyfrowania „tylnych drzwi”, które umożliwią organom ścigania dostęp do danych w tranzycie i na urządzeniach. Jak Vice Magazine Płyta zwięźle go umieścić ich nagłówek, „Republikanie, którzy nie rozumieją szyfrowania, przedstawiają Billowi, żeby to złamał”.

Projekt ustawy senatorów Lindsey Graham (R-South Carolina), Toma Cotton (R-Arkansas) i Marsha Blackburn (R-Tennessee) był szeroko i dokładnie krytykowany przez przemysł technologiczny, obrońców praw obywatelskich i wielu z nich kierując się zdrowym rozsądkiem. Jak Thomasa Claburna artykuł w Rejestrze wyjaśnia:

Ustawa wymaga, aby każda firma przedstawiła nakaz - „producent urządzenia, dostawca systemu operacyjnego, dostawca usług zdalnego przetwarzania danych lub inna osoba” - aby pomóc władzom w „uzyskaniu dostępu do informacji przechowywanych na urządzeniu elektronicznym lub dostępu do informacji przechowywanych zdalnie. ”

 Nie określa, jak należy postępować z szyfrowaniem, tylko że powinno być możliwe do cofnięcia, gdy jest niewygodne dla władz…

 … Należy powiedzieć, że szyfrowanie zapobiega również sporym przestępstwom, zapewniając odpowiednie bezpieczeństwo kont bankowych i przeglądanie stron internetowych. Nakazanie backdoora, który matematycznie każdy mógł znaleźćmoże nie być najmądrzejszym posunięciem.

Niestety, ta próba legislacji nie jest nawet szczególnie nowa, tylko ostatnia leniwa iteracja próby ominięcia bezpieczeństwa cyfrowego, aby ułatwić życie Mocom, które są.

Na wynos SSL.com: SSL.com nie obsługuje braku bezpieczeństwa wymaganego przez rząd - gdy szyfrowanie od końca do końca jest zabronione, tylko wyjęci spod prawa będą mieli szyfrowanie od końca do końca. Zwróć także uwagę na cytat z artykułu Vice: „Jedyne zastrzeżenie to„ chyba, że ​​niezależne działania niepowiązanego podmiotu uniemożliwiają to technicznie ”, co wydaje się wykluczać obecną rzeczywistość, która polega na tym, że same firmy technologiczne uniemożliwiły to do odszyfrowania danych przechowywanych w telefonie zaszyfrowanym za pomocą hasła lub wiadomości wymienianych w kompleksowo zaszyfrowanych aplikacjach ”.

Rząd Stanów Zjednoczonych planuje używać protokołu HTTPS we wszystkich witrynach internetowych .gov

W dobrych, spóźnionych wiadomościach rząd Stanów Zjednoczonych ogłosił zamiar dodania domeny „.gov” do listy wstępnego ładowania HTTP Strict Transport Security (HSTS). Na razie niektóre witryny rządowe będą nadal oferować HTTP, aby były dostępne dla użytkowników, z zamiarem osiągnięcia punktu, w którym wszystkie serwery sieciowe .gov będą domyślnie używać HTTPS.

Ale to jest rząd federalny i ważne jest, aby pamiętać, że nic z tego nie nastąpi z dnia na dzień. Zamiast tego Stany Zjednoczone pracują nad umieszczeniem domeny .gov na liście wstępnego ładowania HSTS, co w końcu to nastąpi przekierowywać użytkowników do komunikacji przez HTTPS jako domyślny.

Cena Od zapowiedział rządt:

Zwróć uwagę, że ogłaszamy zamiar wstępnego załadowania TLD, ale tak naprawdę nie ładujemy go dzisiaj. Gdybyśmy to zrobili, niektóre witryny rządowe, które nie oferują HTTPS, stałyby się niedostępne dla użytkowników i nie chcemy negatywnie wpływać na usługi na naszej drodze do ich ulepszania! W rzeczywistości wstępne ładowanie jest prostym krokiem, ale osiągnięcie tego będzie wymagało wspólnych wysiłków ze strony federalnych, stanowych, lokalnych i plemiennych organizacji rządowych, które korzystają ze wspólnych zasobów, ale nie często współpracują w tej dziedzinie… Dzięki wspólnym wysiłkom możemy wstępnie załadować. gov w ciągu paru lat.

W międzyczasie, zgodnie z tym samym ogłoszeniem, rząd będzie przygotowywał poszczególne strony do przejścia, przeprowadzał prezentacje i sesje odsłuchowe oraz automatycznie ładował wszystkie nowa Domeny .gov od września. Stworzyli również nowy serwis listowy zawierający informacje zwrotne od agencji rządowych na temat wyzwań, którym spodziewają się sprostać.

Na wynos SSL.com:  Wszystkie witryny internetowe powinny już korzystać z protokołu HTTPS, więc jest to dobry pomysł, choć powolny. Weźmiemy to, co możemy!

Comcast i Mozilla Strike Firefox DoH Deal

Comcast jest pierwszym dostawcą usług internetowych partner z Mozillą zapewnienie zaszyfrowanych wyszukiwań DNS w przeglądarce Firefox. Pojawia się umowa między dwiema firmami po sporze nad prywatnością dostawcy usług internetowych i czy DNS przez HTTPS odbiera dostawcom usług internetowych możliwość śledzenia użytkowników i utrzymywania takich elementów, jak kontrola rodzicielska.

Jon Brodkin w Ars Technica wyjaśnia że Comcast będzie pierwszym dostawcą usług internetowych, który dołączy do programu Firefox Trusted Recursive Resolver, dołączając do Cloudflare i NextDNS. Program, zgodnie z tym artykułem, „wymaga spełnienia przez dostawców zaszyfrowanego DNS kryteria prywatności i przejrzystości i zobowiązujemy się nie blokować ani nie filtrować domen domyślnie, „chyba że jest to wyraźnie wymagane przez prawo w jurysdykcji, w której działa resolver”. ”

Wcześniej obaj obecni partnerzy nie zgadzali się co do DNS przez HTTPS, co uniemożliwia ludziom sprawdzenie, jakie wyszukiwania DNS wykonują przeglądarki, co utrudnia monitorowanie przez dostawców usług internetowych. Z artykułu Ars Technica:

Partnerstwo Comcast / Mozilla jest godne uwagi, ponieważ dostawcy usług internetowych walczyli z planami wdrożenia DNS przez HTTPS w przeglądarkach, a praca Mozilli nad tą technologią ma w dużej mierze na celu uniemożliwienie dostawcom usług internetowych szpiegowania przeglądania ich użytkowników. We wrześniu 2019 roku grupy branżowe, w tym lobby kablowe NCTA, do którego należy Comcast, napisały list do Kongresu sprzeciw wobec planów Google dla zaszyfrowanego DNS w Chrome i Androidzie. Comcast dał członkom Kongresu a prezentacja lobbingowa który twierdził, że plan zaszyfrowanego DNS „scentralizowałby [e] większość światowych danych DNS w Google” i „dałby jednemu dostawcy kontrolę nad routingiem ruchu internetowego i ogromną ilością nowych danych o konsumentach i konkurentach”. Prezentacja lobbingowa Comcast również narzekała na plan Mozilli dla Firefoksa.

Mozilla w listopadzie oskarżeni dostawcy usług internetowych okłamywania Kongresu w celu szerzenia zamieszania na temat szyfrowanego DNS. Mozilli list do Kongresu skrytykował Comcast, wskazując na plik incydent w 2014 roku w którym Comcast „wstrzykiwał reklamy użytkownikom podłączonym do publicznych hotspotów Wi-Fi, potencjalnie tworząc nowe luki w zabezpieczeniach witryn internetowych”. Mozilla stwierdziła, że ​​z powodu incydentu Comcast i innych związanych z Verizon i AT&T, „Uważamy, że takie proaktywne środki [w celu wdrożenia zaszyfrowanego DNS] stały się konieczne, aby chronić użytkowników w świetle obszernych danych dotyczących nadużywania danych osobowych przez dostawców usług internetowych”. Mozilla zwróciła również uwagę na brak w kraju zasad prywatności szerokopasmowych, którymi były zabity przez Kongres w 2017 r. na zlecenie ISP.

Ale wydaje się, że to już przeszłość, z podpisaną umową między obiema firmami w marcu i oczekiwaniem, że zaszyfrowany DNS firmy Comcast wkrótce pojawi się w Chrome.

Na wynos SSL.com: Dobrze jest widzieć dostawcę usług internetowych, który korzysta z zaszyfrowanego DNS, ale nadal powinieneś czytać Xfinity firmy Comcast Polityka prywatności jeśli jesteś klientem.

AddTrust External CA Certyfikat główny wygasł

Połączenia AddTrust External CA certyfikat główny wygasł w maju 30, 2020. Chociaż większość użytkowników nie będzie dotknięta tym wygaśnięciem, nadal jest godny uwagi. Niektóre certyfikaty wydane w przeszłości przez SSL.com są przesyłane do katalogu głównego Sectigo USERTrust RSA CA za pośrednictwem pośredniego podpisu krzyżowego przez root AddTrust. Zrobiono to w celu zapewnienia zgodności ze starszymi urządzeniami, które nie zawierają katalogu głównego USERTrust.

Na szczęście to urządzenia do zawierać korzeń zaufania USERT, który stanowi zdecydowaną większość, nie będzie miał wpływu na wygaśnięcie. W takim przypadku, co będzie prawdziwe dla wszystkich nowoczesnych przeglądarek, systemów operacyjnych i urządzeń mobilnych, oprogramowanie po prostu wybierze ścieżkę zaufania prowadzącą do USERTrust i zignoruje wygasły certyfikat AddTrust. Wyjaśniliśmy to wszystko na początku miesiąca, więc jeśli szukasz więcej szczegółów, być może chcesz przejdź do naszego posta na blogu z 2 czerwca. Aby zachować kompatybilność ze starszymi urządzeniami, właściciele witryn z certyfikatami SSL.com USERTrust mogą pobrać zastępcze certyfikaty pośrednie i główne za pomocą poniższych przycisków:

POBIERZ INDYWIDUALNE CERTYFIKATY

POBIERZ PAKIET CERTYFIKATÓW

Użytkownicy polegający na starszym SSL /TLS klientów, w tym OpenSSL 1.0.x i GnuTLS, powinien usunąć wygasły certyfikat AddTrust z ich głównego magazynu systemu operacyjnego. Zobacz nasze blogu łącza do poprawek dla Red Hat Linux i Ubuntu.

Na wynos SSL.com: Jeśli posiadasz certyfikaty USERTrust wydane przez SSL.com, możesz (i powinieneś!) Pobrać nowy pakiet CA z naszej strony internetowej i zainstaluj je na swoim serwerze.
Dziękujemy za odwiedzenie strony SSL.com! W razie jakichkolwiek pytań prosimy o kontakt mailowy pod adresem Support@SSL.com, połączenie 1-877-SSL-SECURElub po prostu kliknij łącze czatu w prawym dolnym rogu tej strony. Odpowiedzi na wiele często zadawanych pytań można również znaleźć w naszym baza wiedzy.

 

Subskrybuj biuletyn SSL.com

Nie przegap nowych artykułów i aktualizacji z SSL.com

Będziemy wdzięczni za Twoją opinię

Weź udział w naszej ankiecie i daj nam znać, co myślisz o swoim ostatnim zakupie.