SSL.com은 모든 고객과 방문객 모두가 행복하고 안전하며 건강한 휴가철과 번영하는 2021 년을 기원합니다! 새해가 조금 줄어들기를 바랍니다. 음… 흥미있는 2020 년보다 어떤면에서 보였지만 네트워크 보안, 디지털 인증서 및 네트워크의 중요한 소식 없이는 한 달도 지나지 않을 것입니다. PKI.
OpenSSL DoS 취약성
이 문제는 블로그 게시물 이번 달 초에 반복 할 가치가 있습니다. 의 높은 심각도 취약성 OpenSSL을 1.0.2i 이전의 모든 OpenSSL 1.1.1 및 1.1.1 버전에 영향을 미치는 것으로 밝혀졌습니다. 이 취약점은 DoS (서비스 거부) 공격을 생성하기 위해 악용 될 수 있습니다. 오픈SSL 1.1.1i는 8 년 2020 월 XNUMX 일에 릴리스되었으며 수정 사항이 포함되어 있습니다.
OpenSSL 사용자는 가능한 한 빨리 설치를 업데이트해야합니다. 수정 사항을 적용하는 방법에는 두 가지가 있습니다.
- OpenSSL 1.1.1 사용자 및 지원되지 않는 1.0.2 사용자는 1.1.1i로 업그레이드해야합니다.
- OpenSSL 1.0.2 프리미엄 지원 고객은 1.0.2x로 업그레이드해야합니다.
OpenSSL은 현재 대부분의 HTTPS 웹 서버에 설치되어 있습니다. SSL.com의 취약점에 대해 자세히 읽을 수 있습니다. 블로그, 그리고 OpenSSL 프로젝트의 보안 자문.
Cloudflare, 새로운 개인 정보 보호 프로토콜지지
팀 앤더슨 신고 Register에서 Cloudflare는 " '개인 정보 보호 인터넷'을 가능하게 할 새로운 인터넷 프로토콜 채택을 추진하고 있습니다."이러한 프로토콜에는 개인 정보 보호 강화가 포함됩니다. HTTPS를 통한 DNS (DoH), 추가 암호화 TLS 악수및 사용자 암호 처리를위한 보안 향상.
불명확 한 DoH
HTTPS를 통한 DNS (DoH) DNS 쿼리 및 응답을 암호화하여 인터넷 프라이버시의 취약한 링크를 해결합니다. 불명확 한 DoH (ODoH) DoH 서버가 클라이언트의 IP 주소를 알지 못하도록 방지하여 DNS 개인 정보 보호를 한 단계 더 강화합니다.
ODoH의 핵심은 클라이언트와 DoH 서버 사이에 네트워크 프록시를 도입한다는 것입니다. 프록시는 DoH 서버에서만 읽을 수있는 DNS 쿼리에 대한 가시성이 없습니다. 서버는 클라이언트의 IP 주소를 알지 못합니다. 쿼리는 프록시와 서버가 결합되지 않는 한 비공개입니다.
Cloudflare는 Cloudflare, Apple 및 Fastly의 엔지니어가 개발 한 ODoH에 대한 지원을 이미 선언했습니다. 자세한 내용은 그들의 논문 arxiv.org에서.
암호화 된 클라이언트 Hello (ECH)
암호화 된 클라이언트 Hello (ECH) 향상된 핸드 셰이크 암호화 제공 TLS, 넘어 암호화 된 SNI (ESNI), 서버 이름 표시 (SNI) 만 보호합니다. TLS 악수. Cloudflare 연구 엔지니어 Christopher Patton 쓰기,
ESNI는 상당한 진전을 이루었지만 완전한 핸드 셰이크 암호화를 달성하려는 우리의 목표에는 미치지 못했습니다. 불완전한 것 외에도 SNI 만 보호합니다. 소수의 정교한 공격, 해결하기는 어렵지만 해결해야 할 프로토콜 설계의 이론적 약점을 지적합니다.
...
궁극적으로 ECH의 목표는 TLS 동일한 ECH 서비스 제공 업체 뒤에있는 서로 다른 원본 서버에 대한 연결은 서로 구별 할 수 없습니다.
당연히 ECH는 "DoH와 CDN (컨텐츠 배포 네트워크)의 맥락에서만 완전히 의미가 있기 때문에"Cloudflare는 "자신을 ECH 제공 업체로 간주"합니다. IETF에서 ECH에 대한 자세한 내용을 읽을 수 있습니다. 초안 제안.
OPAQUE 암호
OPAQUE 암호 ( "PAKE (암호 인증 키 교환)와 결합 된 OPRF (Oblivious Pseudo-Random Function)에 대한 일종의 말장난")는 사용자의 암호가 서버로 전송되는 것을 완전히 방지하는 메커니즘입니다. OPAQUE는“서버와 클라이언트가 중개 두 번째 솔트를 사용하여 비교하기 위해 솔트 된 해시를 공동으로 계산하게함으로써이를 달성합니다. 이렇게하면 서버가 인증 중에 사용자의 암호를 알 수없고 사용자가 서버의 비밀 솔트를 알지 못합니다. "
OPAQUE 암호에 대한 자세한 내용은 이 종이 [PDF 링크] University of California, Irvine 및 IBM의 연구원과 Cloudflare 엔지니어 Tatiana Bradley의 블로그 게시물.
SolarWinds 공격에 연결되었을 가능성이있는 유출 된 FTP 자격 증명
멀리 떨어진 독립형 선실에서 지난 몇 주를 보내지 않았다면 (지금은 우리가 생각하고있는 나쁘지 않은 생각이 아닙니다) 공급망 공격 SolarWinds의 Orion IT 모니터링 소프트웨어와 정부 및 업계의 많은 사용자를 손상 시켰습니다. Ravie Lakshmanan의 16 월 XNUMX 일 이야기 in the Hacker News에서는 공격자가 "이른바 2019 년 XNUMX 월에 SolarWinds Orion 플랫폼의 소프트웨어 빌드 및 코드 서명 인프라를 손상시켜 소프트웨어 릴리스 프로세스를 통해 악성 백도어를 제공 할 가능성이 큽니다"에 대해 설명합니다.
아이디어는 ... 빌드 시스템을 손상시키고, 소프트웨어의 소스 코드에 자신의 코드를 조용히 삽입하고, 회사가 컴파일 할 때까지 기다렸다가 패키지에 서명하고, 마침내 수정 사항이 예상대로 새로 출시 된 업데이트에 나타나는지 확인하는 것이 었습니다.
2019 년 XNUMX 월 타임 라인은 보안 연구원 Vinoth Kumer의 발견, 2019 년 123 월, Solarwinds 업데이트 서버의 일반 텍스트 FTP 자격 증명을 유출하는 공개 GitHub 리포지토리에 대해이 서버에 "solarwinds17"이라는 암호를 사용하여 액세스 할 수있었습니다. 문제의 리포지토리는 "2018 년 XNUMX 월 XNUMX 일부터"대중에게 공개되어 공격자가 유출 된 자격 증명을 발견하고 악용 할 수있는 충분한 시간을 제공했습니다.
물론 SolarWinds가 사용자에게 보안 조치를 비활성화하라고 조언 한 것도 도움이되지 않았습니다.
설상가상으로, Orion 소프트웨어 업데이트에 추가 된 악성 코드는 SolarWinds 자체로 인해 표적 시스템의 바이러스 백신 소프트웨어 및 기타 보안 도구에 의해 발견되지 않았을 수 있습니다. 지원 자문, 파일 디렉터리가 바이러스 백신 검사 및 GPO (그룹 정책 개체) 제한에서 제외되지 않으면 제품이 제대로 작동하지 않을 수 있음을 나타냅니다.
