VPN이 KRACK을 막아 주는가? 패치가 고치는 것
VPN은 로컬 네트워크에서 트래픽을 숨기지만 WPA2 핸드셰이크를 고칠 수는 없다. 2017년 패치가 무엇을 바꿨고 각 계층이 무엇을 덮는지 정리한다.
KRACK이 Wi-Fi 암호화를 깨뜨린다는 헤드라인을 보고 VPN을 산다면, 고쳐야 할 계층을 잘못 짚은 것이다. 2017년의 그 공개는 WPA2의 네 방향 핸드셰이크에 대한 키 재설치 공격 계열을 설명했고, 수정은 운영체제 업데이트, 무선 드라이버 패치, 공유기 펌웨어로 도착했다. 터널은 로컬 네트워크에서 트래픽을 숨길 수 있지만, 그 아래에서 끝나는 핸드셰이크를 고칠 수는 없다. 따라서 첫 질문은 어떤 VPN을 살지가 아니라, 어느 기기가 아직 패치되지 않은 무선 스택을 돌리고 있는지이다.
같은 구분이 예산 걱정에도 답한다. 구독료를 낼 수 없는 사람이 진짜 해법에서 배제된 적은 없다, 해법은 무료 업데이트였기 때문이다. 돈이 드는 것은 더 이상 업데이트를 받지 못하는 하드웨어를 바꾸는 일이다.
공격이 실제로 조작한 것
WPA2는 연결 시 네 방향 핸드셰이크로 새로운 쌍별 키를 유도한다. 액세스 포인트가 논스를 보내고, 클라이언트는 자기 논스로 응답하며, 양쪽이 쌍별 임시 키를 계산하고, 액세스 포인트는 클라이언트가 확인하는 메시지로 확정한다. 키 재설치 공격은 암호 문구를 추측하는 대신 그 순서에 개입해, 이미 설치한 키를 클라이언트가 다시 설치하게 만든다. 재설치마다 그 키에 묶인 전송 논스와 수신 재생 카운터가 되돌아갈 수 있다.
그 카운터가 뒤로 가면 거부되어야 할 트래픽 일부가 다시 받아들여진다. 변종과 구현에 따라 전파 범위 안의 공격자는 프레임을 재생하거나 복호화하거나 주입할 수 있었다. 그룹 키 핸드셰이크와 빠른 전환 핸드셰이크에는 각자의 변종이 있었고, 권고가 하나가 아닌 여러 공격 이름을 나열한 이유가 그것이다.
Android 6.0 이후가 최악의 사례였다. 그 wpa_supplicant 버전은 전부 제로인 키를 설치하도록 밀어붙일 수 있었고, 재설치가 카운터만 되돌리는 플랫폼보다 복호화가 훨씬 쉬워졌다. 그 세부가 당시 가장 흔한 휴대전화 플랫폼에서 이론적 약점과 실제 약점을 갈랐다.
수정은 무선 스택 안에 있다
업스트림 수정은 키가 이미 설치되어 있으면 재전송된 핸드셰이크 메시지를 무시하라고 서플리컨트와 액세스 포인트에 지시했다. 패치된 wpa_supplicant와 hostapd 빌드가 그것을 담았고, 배포판은 오래된 브랜치로 역이식했으므로 wpa_supplicant -v이 출력하는 문자열은 판결이 아니라 출발점이다. 배포판의 보안 권고를 읽고 버전 번호만이 아니라 특정 패치를 확인하라. 오래된 버전을 보고하는 빌드도 고쳐졌을 수 있고, 새 버전 빌드도 공급업체의 역이식을 빠뜨렸을 수 있다.
링크의 양 끝 모두 주의가 필요하다. 고친 공유기는 그것에 접속하는 노트북을 패치하지 않고, 고친 노트북은 공유기를 패치하지 않는다. 공급업체는 제품별 권고를 냈고, 공유기 수정은 모델마다 고유한 펌웨어 빌드가 필요해 휴대전화 업데이트보다 늦는 일이 흔했다. 기기의 마지막 릴리스가 권고보다 앞선다면 공급업체가 반대말을 하기 전까지 패치되지 않은 것으로 취급하라.
업데이트할 수 없는 장비라면 선택지는 좁고 화려하지 않다. 폐기하거나, 민감한 트래픽을 나르는 네트워크에서 떼어 두거나, 유일한 동료들도 똑같이 버릴 수 있는 세그먼트에 가두어라. 어느 선택지도 구독을 필요로 하지 않고, 다른 터널 사업자를 고른다고 나아지지도 않는다.
터널이 덮는 것
VPN은 경계를 옮긴다. 기기는 각 패킷을 암호화해 VPN 서버로 보내고, 서버는 그것을 복호화해 앞으로 전달한다. Wi-Fi 링크를 조작하는 사람은 터널의 바깥 패킷을 보지 안쪽 페이로드를 보지 못하므로, 링크 계층 프레임을 노출하는 재설치 공격이 터널로 감싼 연결의 내용을 자동으로 노출하지는 않는다. 그 보호는 아래의 무선 스택이 여전히 취약해도 유지되며, 두 통제가 혼동되는 이유가 바로 그것이다.
단서는 "터널로 감싼"이다. 분할 터널링, 우회 목록, 캡티브 포털 예외는 일부 트래픽을 터널 밖으로 보내고, 그 트래픽은 아무 이득도 얻지 못한다. 같은 네트워크에서 클라이언트를 한 번도 설치하지 않은 다른 기기의 트래픽도 마찬가지다. 터널은 기기별, 경로별 결정이지 방의 속성이 아니며, 공유기 수준 VPN은 실제로 공유기를 지나는 것만 덮는다.
터널이 못 하는 것은 드라이버를 고치거나, 인증 해제 폭주를 멈추거나, 공격자가 채널을 방해하지 못하게 막는 일이다. 한 번도 들어오지 않는 연결을 보호할 수도 없다. 이는 가용성과 링크 계층의 문제이며, 터널의 암호 제품군이 아무리 강해도 무선 스택 쪽에 남는다.
HTTPS와 터널은 서로 다른 구간을 보호한다
페이지 한 번 로드에 세 가지 보호가 관여할 수 있다. Wi-Fi 링크, VPN 서버로 가는 터널, 웹사이트로 가는 TLS 세션이다, 각각 독립적으로 협상된다. 유효한 인증서와 현대적 프로토콜 버전을 갖춘 TLS는 첫 구간이 적대적이어도 브라우저와 사이트 사이에 인증된 암호화를 준다, 사칭자가 자기 키를 끼워 넣지 못하게 막는 것이 인증서 검사이기 때문이다.
그 검사에는 가장자리에 약점이 있다. HTTPS에서 HTTP로의 리디렉션, 평문 HTTP로 스크립트를 불러오는 페이지, 인증서 경고를 클릭해 넘어가는 사용자는 모두 트래픽을 보호된 세션 밖으로 옮긴다. HSTS와 브라우저 중간 페이지가 있는 것은 그런 실수가 흔하기 때문이지 TLS가 약해서가 아니다.
HTTPS와 터널을 유지한다고 무선 구현이 취약하지 않게 되지는 않는다. 프레임은 여전히 결함 있는 드라이버가 복호화하며, 차이는 공격자가 그 안에서 무엇을 찾는지, 그 내용이 이미 다른 무엇으로 보호되고 있었는지이다.
혼합 네트워크의 수정 순서
액세스 포인트부터 시작하라, 당신이 통제하고 모든 클라이언트가 의존하는 기기이기 때문이다. 다음으로 클라이언트 운영체제를 오래된 것부터 훑어라, 업데이트를 받지 못하게 된 플랫폼이 결코 패치되지 않을 것이기 때문이다. 그 목록이 끝난 뒤에야 VPN 결정이 의미를 가지며, 그것은 수정이 아니라 노출에 관한 결정이다. 반대 순서로, 먼저 터널을 두고 나중에 펌웨어를 두면 구독이 이어지는 동안 실제 결함은 제자리에 남는다.
무엇을 확인했는지 펌웨어 버전과 날짜를 포함해 적어 두라. "업데이트됨"은 나중에 누구도 감사할 수 없는 상태다.
세 가지 확인이 작업의 대부분을 덮고, 순서는 이렇다. 처음 둘이 깨끗했다고 해서 셋째를 건너뛰지 마라.
- 공유기 펌웨어: 설치된 버전을 업데이트 버튼이 아니라 공급업체의 권고 페이지와 비교하라.
- 클라이언트 OS: 각 휴대전화, 노트북, 태블릿에 무선 수정을 포함한 패치 수준을 확인하라.
- 남은 것: 패치 경로가 없는 기기를 나열하고 폐기, 격리, 수용 중 하나를 정하라.
남은 목록이 길면 클라이언트 격리가 있는 게스트 네트워크가 하드웨어를 교체하는 동안 시간을 벌어 준다. 그다음 각 대역에서 알려진 클라이언트 하나를 시험하고 결과를 기록하며, 다음 펌웨어 릴리스 뒤에 다시 확인하라. 다음 권고를 빠르게 만드는 것은 하드웨어 목록이고, 그 사이의 틈을 덮는 것은 터널이다.