- 상위 문서 : 엣지(웹 브라우저)
Internet Explorer 11에서도 10에 비해 보안에 있어서는 많은 것이 향상되었던 것 처럼 Microsoft 의 최근 몇 년간의 행보는, 이전에 비해 Memory Corruption 류의 취약점을 이용하는 해킹에 대한 방어도 꽤나 적극적으로 하는 것을 보여주고 있다. 이번 Edge 브라우저에서도 역시 새로운 보안 기능이 많이 추가되었다. 아래의 내용들은 모두 여기 에서 공식적으로 발표된 내용에 기반한 것이다.
1. 해킹 방어 기능
1.1. ActiveX를 포함한 각종 레거시 기술들의 지원 제거
이 문서에서도 줄기차게 언급되고 있고, 위 출처에서도 가장 먼저 나오는 내용인 만큼 그 중요성이 어느 정도인지는 굳이 얘기할 필요가 없을 것이다. 정확히 말하자면, 단지 ActiveX의 제거가 아니라 VML(Vector Markup Language)[1], VBScript[2], BHO(Browser Helper Objects)[3], ActiveX를 모두 제거한다는 것이다. ActiveX의 경우, 이를 제거하는 대신 더 보안성이 향상되고 HTML/자바스크립트 기반의 다른 확장 기능 모델을 추가한다는 내용이다. 아직 발표되지는 않았으나 오래 안가서 소개될 것이라 생각된다.이는 IE에서만 지원하는 오래된 것들을 모두 제거하고, 보안성에 있어서도 문제가 되어 왔던 것들을 제거함으로서 상당히 큰 발전이라고 할 수 있다. 구글의 경우에도 NaCl(Native Client) 등의 고급 기술을 개발해서 샌드박스 내에서 서드파티 바이너리(확장기능 등)를 실행하는 것을 어렵사리 구현하고 있는데, ActiveX와 같이 아무런 부가적인 보안 요소 없이[4] 그대로 로컬 액세스 권한을 주는 것은 지금 시대에서는 심각하게 뒤떨어진 것이다. 이를 마이크로소프트도 예전부터 인식하고 있었으나 호환성으로 인해 쉽게 제거하지 못하였는데 이제 엣지라는 별개의 브라우저로 개발하게 되면서 이를 모두 제거할 수 있는 일종의 기회를 얻었다고 볼 수 있다.
1.2. 유니버설 윈도우 앱
엣지는 유니버설 윈도우 앱 기반으로 개발되었다. 이는 유니버설 윈도우 플랫폼(UWP) 기반으로 동작하는 애플리케이션으로, Windows 8에서 처음 소개된 것이다. 이름 그대로 모바일 기기와 데스크톱 PC 등을 모두 아우르는 앱을 개발하는 것인데, 엣지는 이 유니버설 앱으로 개발되었다. 언뜻 보면 이는 보안과는 별 관계는 없어 보이지만, 유니버설 윈도우 앱의 경우 애플리케이션에서 구현을 따로 하지 않아도 기본적으로 적용되는 보안 모델이 별개로 존재한다. 쉽게 말해서 마치 OS X 처럼 애플리케이션이 동작할 때 기본으로 샌드박스가 한 층 추가된다고 보면 된다.[5] 실제로 엣지를 실행하고 처음 프로세스를 확인해 보면 Integrity Level이 AppContainer인 것을 볼 수 있다. 반면 인터넷 익스플로러의 경우 그냥 일반적인 프로그램이기 때문에 처음 실행되는 Broker 프로세서의 Integrity Level은 보통의 기본 유저 권한인 Medium이다.다만 실제로 이로 인한 보안성을 이렇게 간단하게 나타낼 수는 없고, 무조건 보안성이 강화되었다고도 볼 수 없다. 현재 IE11 전환을 위한 것으로 추측되는 Medium 권한의 browser_broker.exe라는 프로세스가 따로 동작하고 있고 기존에 Broker(처음 실행한 프로세스)의 자식 프로세스로 Renderer 프로세스가 생성되었던 것과 달리 엣지의 경우 렌더러 프로세스가 RuntimeBroker.exe라는 Medium Integrity Level을 가지는 새로운 프로세스의 자식으로 생성된다. 아예 렌더링을 위한 프로세스는 프로그램 자체가 분리되어 MicrosoftEdgeCP.exe라는 이름으로 존재한다.(어찌 됐든 브라우저라는 프로그램은 로컬 리소스에 액세스가 필요하다. 파일을 다운로드해서 저장한다든지......) 그리고 MicrosoftEdgeCP.exe(Content Process)에서 웹 서버와의 소켓 통신을 개별적으로 직접 하고 있는 모습을 볼 수 있다. 이쪽 부분은 추후 구조가 자세히 판명되면 추가바람.
여하튼 이런 것이 가능한 이유는 위에서 언급했다시피 유니버설 윈도우 앱은 기본적으로 유니버설 윈도우 플랫폼이라는 플랫폼 위에서 동작하도록 되어 있기 때문이다. OS X의 경우에도 순수 커널 아래에서 동작하는 바이너리들이 샌드박스 내에서 동작하는 것이 아니라, XNU 커널 위에 또 다른 플랫폼을 쌓아 올리고, 이 플랫폼이 샌드박스를 구현하고, 개발자들은 그 새로운 플랫폼 대상으로 애플리케이션을 개발하는 식으로 하기 때문에 가능한 것이다. 즉 샌드박스 구조에 비유하면 UWP와 같은 플랫폼이 알아서 Broker 역할을 하는 것이다. 다만 OS X는 예전부터 이렇게 동작하는 것이 기본 옵션이었고 개발자들도 오랫동안 그렇게 개발해왔기 때문에 거의 모든 애플리케이션이 이렇게 동작하고 있지만, 윈도우는 윈도우 8에 와서야 소개했기 때문에 아직 적용이 늦다는 차이 뿐이다. 물론 아직까지도 윈도우는 이렇게 개발하는 것이 기본이 아니기 때문에 대부분의 응용 프로그램은 샌드박스 내에서 안전하게 동작하는 것이 아니라 지금까지처럼 '날것'으로 실행될 것이다.
1.3. AppContainer 샌드박스
인터넷 익스플로러 7에서 보호 모드라는 보안 모델을 소개했다. 이는 기본적으로 Integrity Level이라는 Windows의 새로운 권한 모델을 기반으로 하는 것인데, Windows XP 이하의 운영체제에서는 이런 것이 존재하지 않았고 Windows Vista에서 처음으로 소개되었다. 따라서 정확히는 Vista 이상(더 정확히는 UAC가 켜져 있을 때만)에서 동작하는 인터넷 익스플로러 7부터 보호모드가 적용되었다. 이는 샌드박스 모델인데, 브라우저가 페이지를 렌더링하는 데에 쓰는 프로세스를 따로 분리하여 이 분리한 프로세스의 권한을 낮게 주는 것이라고 보면 된다. 즉 제 3자가 만든 HTML 페이지에서는 IE의 취약점을 이용하는 악의적인 자바스크립트 코드 등이 있을 수 있는데, 이를 실행하면서 취약점이 발생하기 때문에 이런 렌더링 관련 작업은 따로 자식 프로세스를 생성하여 그 안에서 처리한다. 그러면 만약 여기서 취약점이 발생한다고 해도 이 프로세스 자체로는 권한이 낮기 때문에, 시스템의 중요 파일 등에 접근을 할 수 없으며 더 높은 Integrity Level을 가지는 프로세스에 (악성)코드 삽입 등을 하는 것도 불가능하며 그 외에도 시스템의 다양한 리소스들에 접근을 할 수 없다. 따라서 취약점으로 임의 코드 실행을 할 수 있다고 해도 해커가 시스템에 해를 끼치는 것에 한계가 있다.이러한 보호 모드는 IE10부터 향상된 보호 모드(EPM)로 다른 보안 기능도 추가하면서 더욱 발전하였고 지금까지 계속 적용되어 왔다. Windows 8에서는 위에서 언급한 Integrity Level의 종류(System, High, Medium, Low, Untrusted)에 AppContainer를 하나 더 추가하였는데, 이는 이름에서 알 수 있다시피 앱으로 개발된 애플리케이션들이 기본으로 이 권한으로 동작한다. EPM은 Windows 8이상에서 브라우저가 동작할 때 렌더링 프로세스를 AppContainer 권한으로 실행하도록 한다.
다만 이는 실제로 브라우저가 App으로 개발되어 동작하는 것과는 다르다. App으로 개발한 애플리케이션은 그냥 실행하면 권한 자체가 기본적으로 AppContainer가 되고 App 플랫폼 내의 샌드박스에서 기본적으로 동작한다. 그러나 이 경우는 브라우저를 실행하면 처음 실행한 프로세스(Broker)의 Integrity Level은 그대로 Medium이다. 따라서 이는 App 플랫폼에 의한 것이 아닌 IE가 직접 구현한 샌드박스 모델에서 AppContainer 권한을 사용한 것 뿐이다.
즉 정확히는 이는 이미 IE10부터 적용이 되어 있었으나, 엣지에서 변경된 점은 IE10/11에서 EPM이 옵션으로 되어 있었기 때문에 기본값이 아니었던 점을 바꾸어 이제는 무조건 기본으로 적용하도록 바뀌었다. 당연히 이로 인해 보안성은 훨씬 더 강화되었다. 지금까지 이를 기본값으로 하지 못한 이유는 이 샌드박스라는 것은 치명적인 단점(?)으로 ActiveX와 같은 기존의 플러그인 실행에 문제가 생기기 때문이다. 샌드박스는 로컬 리소스에 액세스하는 것을 제한하는 기능인 반면 ActiveX는 로컬 리소스에 거의 제한 없이 액세스할 수 있는 기능이다. 따라서 페이지를 샌드박스 내에서 실행하는 경우 ActiveX와 같은 플러그인이 정상적으로 실행될 수가 없다. 다만 이는 곧 EPM의 적용은 ActiveX의 원천 차단을 의미하기 때문에 마이크로소프트에서도 당연히 이를 해결하기 위해 샌드박스와 호환이 되는(로컬 파일에 액세스하지 않는다거나) ActiveX 플러그인의 경우 EPM 내에서 실행을 할 수 있도록 하는 새로운 기능을 추가했었다. 물론 이는 기존의 ActiveX 플러그인을 그대로 사용할 수 있다는 것은 아니고, 다시 빌드해야 한다는 단점은 있었으나 Flash 등의 중요 플러그인은 이런식으로 호환되게 사용할 수 있었다. 물론 대부분의 ActiveX 플러그인은 로컬 리소스에 액세스해야하는 경우가 대부분이기 때문에 호환되게 할 수 없다.
엣지는 ActiveX와 같은 플러그인을 아예 제거해버렸기 때문에 샌드박스를 강제 적용하는 것에 아무런 문제가 없고, 따라서 이렇게 기본으로 지원을 하게 된 것이다. 이는 ActiveX라는 플러그인의 자체적인 보안과는 별개로, 이렇게 서드파티 바이너리를 아무런 보안 없이 네이티브로 실행하는 기능을 브라우저에서 제거해야하는 또 다른 이유였다고 할 수 있다. PWN2OWN과 같은 대회에서도 브라우저를 해킹할 때 샌드박스도 우회해야 해킹을 한 것으로 인정하는 만큼 샌드박스라는 보안 모델의 중요성은 이루 말할 수 없으며, 심지어 Adobe Reader 같은 소프트웨어도 자체적으로 샌드박스를 구현하고 있을 정도이다.
1.4. 64비트 프로세스
인터넷 익스플로러도 64비트 운영체제에서 64비트로 동작하는 것을 지원하였으나, 옵션으로 64비트 프로세스 사용 설정을 따로 해야 하는 경우가 있었다.[6] 엣지는 64비트 운영체제인 경우 기본적으로 64비트 프로세스로 동작을 하게 되어 보안성이 향상되었다. 64비트인 경우 보안에 있어서 잇점이 되는 부분은 ASLR(Address Space Layout Randomization)에 있어서 32비트보다 훨씬 더 큰 entropy를 가지는 랜덤성이 가능하다는 점이다. 이는 애플리케이션이 적재되는 Base Address에 랜덤성을 부여하는 기능으로, Windows Vista에서 처음 소개된 이후로 exe의 옵션으로 설정할 수 있던 시대를 지나 지금은 강제로 적용하고 있다.기본적으로 Windows에서 32비트 프로세스의 경우 프로세스 주소 공간이 2^32(0x00000000 ~ 0xFFFFFFFF)로 제한이 되고, 여기서 커널 공간을 제외하면 0x00000000 ~ 0x7FFFFFFF )까지의 메모리에만 액세스가 가능하다.(※이는 PAE 등의 기능으로 달라질 수 있으나 기본 설정을 기준으로 설명하였다.) 즉 32비트 주소 공간에서는 주소가 위치할 수 있는 경우의 수도 그 만큼 작으므로 추측이 비교적 쉽다.[7] 그러나 64비트의 경우 2^64 라는 어마어마한 주소 공간을 사용할 수 있고(물론 x86_64(x64) 아키텍쳐에서는 2^48 만 사용하지만 이 역시 32비트에 비하면 엄청나다.) 이는 사실상 추측이 불가능한 entropy로 ASLR을 적용할 수 있다.
2. 메모리 손상 방어
2.1. MemGC
MemGC의 경우 정확히는 엣지만의 보안 기능이라기 보다 Windows 10에서 동작하는 엣지와 IE에 대한 보안 기능이기 때문에 이 문단에 넣기는 조금 애매하긴 하지만 일단 엣지가 나옴과 동시에 새로 소개된 보안 기능이기 때문에 여기서 간단하게만 소개를 하도록 한다. 좀 더 자세한 내용은 여기와 좀더 쉽게 잘 설명된 여기를 참고하자.이것은 기능이라기 보다는 메모리 관리와 관련한 동작 알고리즘의 추가/변경이라고 하는 것이 더 적절하다. 이것은 Use-After-Free 공격을 방어하기 위한 기법이며, 다른 종류의 버그(Buffer Overflow, Out-of-bound Read/Write, etc..)와는 별 상관이 없는 내용이다. 현재 가장 활발하게 발견되고 이용되는 취약점이 대부분 Use-After-Free 취약점이기 때문에 마이크로소프트는 IE11부터 이 공격에 대해 적극적인 방어 기법을 선보여왔다. 대표적으로 과거 IE11에서 이미 적용된 Isolated Heap, Memory Protector 등을 예로 들 수 있다. MemGC의 경우 과거의 Memory Protector 를 한 단계 더 강화한 것으로 보면 된다. 그러니까 즉 MemGC는 엄밀히 말해서 전혀 다른 새로운 보호 기법이라기 보다 Memory Protector 를 대체할 수 있는 발전된 기법이다. 또한 레지스트리 설정값 변경으로 과거 Memory Protector를 사용할지 MemGC를 사용할지 선택도 가능하다.(물론 일반 사용자는 건드릴 필요가 전혀 없다.)
MemGC는 Memory Garbage Collector의 약자이고 이름 그대로 기존 IE의 일부 메모리 관리자를 보안적인 측면에서 좀 더 개선한 것이다. 할당/해제 과정과 가비지 컬렉션등에서 기존의 Memory Protector에서 사용하던 기법들보다 한 단계 더 보안성을 강화하였다. 좀 더 기술적으로 자세한 내용은 위의 링크들을 참조하면 된다. 이러한 내용들은 모두 마이크로소프트가 Memory Corruption 류의 버그에 적극적으로 대응을 할 의지가 IE11에 이어 여전히 현재 진행형이라는 점을 시사한다.
2.2. 제어 흐름 보호
Visual Studio 2015에 적용된 기능으로, 컴파일시 포인터 기반 간접 점프를 확인하는 기능이다. 메모리 손상 취약점의 목표는 해커가 원래 프로그램 코드 중 간접 점프 코드를 통해 자신이 원하는 새로 넣은 코드로 점프해 악성코드를 실행하는 것이다. 제어 흐름 보호는 이런 점프 목적지를 원래 코드 함수 시작점으로 제한해 메모리 손상 취약점을 방어해 해커의 의도를 무력화시키려는 것이다. 엣지를 컴파일할 때 이 기능을 넣고 컴파일했다고 한다. IE에도 적용된 기능이다.3. 바이너리 주입 보호
3.1. 기존 브라우저의 문제점
해커가 브라우저에 동적 라이브러리를 집어넣어 브라우저의 보안 기능을 우회하고 브라우저에 추가적인 광고를 띄우는 경우가 있다. 이를 통해 추가적인 광고 등을 넣어 이득을 보는 경우가 있다. 직접 브라우저 확장 프로그램 설치를 통해 동적 라이브러리를 주입하거나 아니면 위의 메모리 손상 취약점을 통해 강제로 주입할 수 있다. 이것이 가능한 이유는 브라우저에서 확장 프로그램을 로드할 때 동적 라이브러리의 인증 여부를 검사하지 않기 때문이다.3.2. 모듈 코드 통합 강제 기능
그래서 EdgeHTML 13부터 엣지에서 로드하는 모든 동적 라이브러리는 WHQL 인증을 받아야 한다. 여러분이 설치하는 거의 대부분의 드라이버는 마이크로소프트에서 WHQL 인증을 받는데, 이는 대부분 드라이버가 관리자 권한을 가지기 때문이다. 이것을 똑같이 브라우저 동적 라이브러리에도 적용시킨다고 보면 된다. 엣지는 WHQL 인증을 받은 라이브러리만 로드하고, 아닌 라이브러리들은 막는다. 이 기능을 프로세스 단에서 할 수도 있고, 커널 단에서 할 수 있는데, 프로세스 단에서 하면 프로세스가 감염됐을 때 기능이 작동하지 않을 수 있다는 단점이 있다. 그래서 윈도우 커널 단에서 라이브러리를 확인해 프로세스가 감염되어도 커널에서 프로세스를 강제로 꺼버릴 수 있고, 프로세스에서 커널에 접근하기도 힘들어 이 기능을 유지할 수 있다.4. 스마트스크린 필터를 통한 드라이브-바이 다운로드 공격 방어
4.1. 드라이브 바이 다운로드 공격
스마트스크린 필터는 URL 평판과 앱 평판을 기반하여 악성 URL을 차단하고, 악성 프로그램을 받지 못하게 하는 기능이다. 그래서 많은 악성 웹사이트에 사용자들의 접근을 막아 브라우저를 안전하게 한 기능이다. 그래서 드라이브-바이 다운로드(Drive-By download) 공격이라는 것이 생겼는데, 이는 기존의 잘 알려진 웹사이트를 해킹해 자신의 악성코드를 사이트에 올리고, 그 웹사이트에 접속한 사용자들을 취약점을 통해 감염시키는 공격이다. 이렇게 하면 평판 기반 방어는 그 사이트가 잘 알려진 웹사이트이기 때문에 성공적으로 방어할 수 없다. 이런 드라이브-바이 다운로드 공격은 보통 취약점 킷(익스플로잇 킷;여러 취약점들을 동시에 노리는 코드)을 통해 이뤄지며, 많은 사용자들이 모든 프로그램을 제때 업데이트하지 않기 때문에 성공할 확률이 높다. 특히 현재 추세가 아래와 같이 이런 취약점 킷 공격이 많아지고 있는 추세라 사용자들이 더욱 위험해질 수 있다.
그래서 윈도우 디펜더, 엣지, 인터넷 익스플로러, 빙, EMET 등의 툴들을 통해 수집된 악성 신호들을 실시간으로 스마트스크린 필터에 적용해 이런 취약점 킷 공격을 방어하는 것이다. 실제로, 이 기능을 통해 HanJuan EK라는 취약점 킷이 디펜더와 EMET에 잡히자 마자 스마트스크린 필터에 등록되고, 조사를 통해 이 취약점 킷이 어도비 플래시 플레이어 제로데이 취약점을 이용한다는 것을 알아냈다. 이 취약점은 CVE-2015-0313로 명명되었다.
4.2. 스마트스크린 필터 개선
이런 드라이브-바이 다운로드 공격을 방어하기 위해서는 이런 공격들이 웹페이지가 렌더링 되기 전에 탐지되고 차단되어야 한다. 이는 브라우저 성능에도 미칠 수 있기 때문에, 스마트스크린 필터는 작은 캐쉬 파일에 악성 파일을 기록하고, 그걸 기반으로 드라이브-바이 다운로드 공격을 방어한다. 새로운 악성코드가 계속 나오기 때문에, 당연히 이 캐쉬 파일은 주기적으로 업데이트된다.URL이 악성으로 판명되면 다음과 같이 대문짝만하게 웹페이지가 위험하다고 알려준다.
또한, 프레임 단위 경고 기능을 추가해, 위험한 광고 프레임만 차단하고 나머지 정상적인 부분들은 렌더링하는 기능도 추가했다. 그래서 일부만 문제가 있어도 전체 내용을 보지 못하던 경험을 개선했다고 한다.
만약에 스마트스크린 필터가 오탐했다고 생각되면 자세한 정보 링크를 통해 경고 페이지를 확장해 우회할 수 있지만 추천하지는 않는다. 프레임 단위로 차단되었을 경우에는 안전하지 않은 콘텐츠 뱃지를 눌러서 똑같이 우회할 수 있다. 그리고 기존의 스마트스크린 설정과 컨트롤들(그룹 정책 포함)은 새 드라이브-바이 다운로드 공격 보호 기능을 자동으로 추가했다.
4.3. 신고 기능
스마트스크린 필더가 차단하지 않았지만 웹페이지가 위험하다고 생각되면 다음과 같이 마이크로소프트에 보고할 수 있다.- 엣지: 자세한 메뉴에 들어가 피드백 보내기를 누르고 안전하지 않은 웹사이트 보고를 선택하면 된다.
- 윈도우 10의 익스 11: 툴 버튼을 누르고, 안전 탭에서 안전하지 않은 웹사이트 보고를 선택하면 된다.
5. 플래시 콘텐츠 자동 일시 정지
안전하고 좋은 성능과 안정적인 브라우저를 제공하기 위해 플래시의 리소스와 전력을 조정했다. 1주년 업데이트부터 웹페이지에서 중요하지 않은 플래시 콘텐츠는 자동으로 일시정지된다.애니메이션이나 광고같은 주변부 콘텐츠는 유저가 콘텐츠를 재생하도록 클릭을 하지 않는 이상 일시정지된 상태로 있을 것이다. 이로 인해 전체 콘텐츠를 재생하는 것 보다 전력 소모가 감소하고 성능이 향상될 것이다. 비디오나 게임같은 페이지 중심에 있는 콘텐츠는 일시정지되지 않는다.
또한 웹 표준의 기능을 더더욱 강화시켜 더 안전하고 성능이 향상된 경험을 플래시 없이 사이트들이 제공할 수 있도록 노력한다고 한다. 웹 표준을 사용할 때 배터리 수명이 늘어나고 CPU 부하와 메모리 소모가 감소한다고 한다. 개발자들은 웹표준을 통해 모든 브라우저와 모바일 같은 플래시를 쓸 수 없는 장치에서 사이트들이 잘 작동하게 만들 수 있다.
6. Windows Hello 지원
빌드 2016에서 마이크로소프트 엣지가 전 세계에서 처음으로 안전하고 쉽게 웹에서 인증을 할 수 있게 Windows Hello를 지원하는 브라우저가 될 것이라고 발표되었다. 이는 웹 인증 (이전에는 FIDO 2.0 Web API로 불림)의 초기 구현에 의해 작동하고, FIDO Alliance와 W3C 웹 인증 작업 그룹에서 이들 API를 표준화하기 위해 작업하고 있다고 한다. 테스트 드라이브 데모에서 이를 체험해볼 수 있다.기존 패스워드에 많은 문제점들이 있는데, 많은 사람들이 모든 사이트들에 대해 강력하고 전부 다 다른 패스워드를 쓰지 않는다는 것이다. 보통 기억하기 쉽게 만들거나 모든 계정들에 대해 같은 패스워드를 사용한다. 또, 패스워드를 바꾸더라도 "123456"이나 "password" 같은 쉬운걸로 바꾸는 경우가 많다. 해커들은 보통 사회 공학적 기법, 피싱, 키로깅 기법으로 개인 컴퓨터에서 패스워드를 빼내게나, 패스워드를 저장한 사이트를 장악해서 빼내는 경우가 많다. 만약에 패스워드가 여러 사이트에서 동시에 사용된다면, 한 계정만 해킹해도 다른 계정들도 위험해진다.
하지만 이 기술을 통해 인증을 위해 유저가 더 이상 패스워드를 기억하지 않아도 되고, 서버가 저장하지 않아도 된다. 웹 인증과 Windows Hello를 결합해서 생체인식 기술과 비대칭 암호화를 통해 구현한다고 한다. 유저를 인증하기 위해서, 서버가 브라우저에 평문 텍스트 문구을 먼저 보낸다. 엣지가 유저를 Windows Hello로 식별할 수 있다면, 시스템이 유저에 할당된 개인키로 문구에 서명하고 인증서를 서버로 보낸다. 만약에 서버가 이 인증서를 공개 키로 인증서를 확인할 수 있다면, 유저에서 온 것을 확인할 수 있고, 유저를 안전하게 인증할 수 있다.
이 키들은 강력한 계정들을 제공할 뿐만 아니라 추측할 수 없고, 원본 외에서 다시 사용될 수 없다. 공개키는 그 자체로 의미 없고, 개인키는 공유되지 않기 때문이다. Windows Hello로 더 좋은 유저 경험을 제공할 뿐만 아니라, 패스워드 추측, 피싱, 키로깅, 서버 데이터베이스 공격으로 계정을 탈취할 수 없다.
6.1. 웹 인증: 패스워드 없이 작동하고, 2단계 인증 지원
FIDO Alliance에 참가해 웹에서 패스워드를 제거하고 강력한 계정을 생성할 수 있도록 여러 기업들과 같이 작업을 하고 있다고 한다. FIDO Alliance의 주 목표는 이런 인터페이스들을 표준화해, 웹사이트들이 Windows Hello와 다른 생체 인식 기술들을 모들 브라우저에서 사용할 수 있게 하는 것이다. FIDO Alliance는 FIDO 2.0 제안을 W3C에 제출했고, 새로 생긴 웹 인증 작업 그룹은 이들 API를 W3C 웹 인증 표준안에 넣기 위해 이들 API를 표준화하고 있다.
웹 인증 표준안은 다음 2가지 인증 시나리오를 정의하고 있다: 패스워드 없이 인증, 2단계 인증. 패스워드 없이 인증하는 경우는, 유저가 웹페이지에 로그인하기 위해 유저 이름이나 패스워드 없이 - Windows Hello만으로 로그인할 수 있다. 2단계 인증의 경우는, 유저가 유저 이름과 패스워드로 로그인하지만, Windows Hello가 2단계 인증을 해 전체적인 인증을 강력하게 할 수 있다.
전통적인 패스워드 인증은 유저가 패스워드를 생성하고 서버에 알려줘서 서버가 패스워드를 해시화해 저장한다. 유저, 또는 패스워드를 취득한 공걱자는 똑같은 패스워드를 어느 장치에서나 서버에 인증하기 위해 쓸 수 있다. 하지만 웹 인증 표준안은 비대칭 키 인증을 사용한다. 비대칭 키 인증에서는, 유저 컴퓨터가 비밀 키와 공개 키로 구성된 강력한 암호화 키 쌍를 생성해, 공개 키를 서버에 제공하고, 개인 키를 컴퓨터의 TPM 같은 전용 하드웨어에 저장해 컴퓨터에서 다른 곳으로 이동할 수 없게 한다. 이 방식은 클라이언트와 서버 둘 다에 대한 공격을 방어할 수 있다 - 다른 곳에서 공격자가 인증하려는 클라이언트 공격은 성립되지 않고, 서버를 공격해도 공개키 리스트만 얻을 수 있다.
마이크로소프트 엣지는 현재 웹 인증 스펙의 초기 구현을 지원한다 - 사실, 최근 작업안이 업데이트되어 현재 구현을 벗어나있고, 표준안 프로세스를 지나면서 스펙이 계속 변경될 것이다. 그래서 현재 API들은 ms-prefix가 붙어있고, 이들 API들은 미래에 바뀔 가능성이 높다. 그래서 표준안이 만들어질 때까지 API들을 업데이트해 변경점을 제대로 지원할 것이다.
웹 인증 API들은 매우 간단한다 - 두 메서드: window.webauthn.makeCredential와 window.webauthn.getAssertion로 구현된다. 이를 지원하려면 서버와 클라이언트 모두 수정을 해야 한다.
7. TCP Fast Open, TLS False Start, TLS 1.3
밑에 설명할 TCP Fast Open, TLS False Start, TLS 1.3으로 성능과 보안 두마리 토끼를 다 잡을 수 있다고 한다. TCP Fast Open은 about:flags 설정에서 켤 수 있다. 다만 Adguard와 같은 네트워크 프로그램을 해당 옵션과 병행하여 쓸 경우 높은 확률로 시스템이 다운된다.7.1. TLS 1.3으로의 여정
금융 정보 같은 중요한 정보들은 인터넷에서 움직일 때 보안이 충족되어야 하고 안정성이 보장되어야 한다. 웹 상의 보안 네트워크 트래픽 절반 이상이 TLS로 채워져있고, 매일 이 숫자는 늘어나고 있다. 현대적인 암호화 자체는 매우 빼르지만, 페이지 리소스를 가져오기 전에 연결을 활성화하기 위해서 키교환을 해야 한다. 각각의 네트워크 상의 추가적인 교환은 연결을 만드는데 한 "왕복 시간"(RTT) 만큼 느리게 만든다.현재 표준에서, TCP 위의 TLS는 교환을 위해 서버 사이에 여러 번 왕복(3-RTT)해야 한다 - 첫번째는 TCP, 두번째는 TLS - 처음 HTTP GET 명령 같은 유용한 정보를 처음 보내기 전에 반드시 수행되어야 한다. 이는 사이트가 콘텐츠를 여러 도메인에 나눴을 떄 더 문제가 된다. 대게, 암호화를 하면 페이지 로딩 시간에 수백 밀리초 정도가 추가된다. 연구자들은 250ms 지연도 사용자들이 다른 웹사이트로 넘어가게 만들 수 있다고 한다.
TLS 1.3은 개발자들이 암호화된 콘텐츠를 전달하면서 이런 지연 시간을 제거할 수 있게 한다. 이 뜻은 현대 암호화와 지속적으로 개선되는 TCP 스택을 계속 사용하면서 성능과 보안을 다 충족시킬 수 있다는 것이다. TLS 1.3은 표준화 과정을 밟고 있고, IETF는 2016년 여름에 발표될 것으로 예상가고 있다. 하지만 TLS 1.3 없이도, TCP Fast Open과 TLS False Start 옵션으로 지연 시간을 3-RTT에서 1-RTT로 줄일 수 있다. 페이지 로딩 시간을 50ms만 줄여도 더 나은 웹서핑을 즐길 수 있다는 것을 고려해보면 된다.
7.2. TCP와 TLS의 전체 핸드 쉐이크
현재 TCP와 TLS 표준은 서버에 3번 왕복해야 한다 (3-RTT). 첫 번쨰 왕복은 TCP 연결 인수를 교환하기 위해 필요하다. 두 번째 왕복에서, 클라이언트와 서버가 연결의 키와 인수를 교환하기 위해 클라이언트 Hello와 서버 Hello로 시작하는 TLS 메시지를 교환한다. 마지막 왕복에서는 TLS 핸드 쉐이크 무결성을 확인하기 위해 클라이언트와 서버 완료 메시지를 교환한다.
7.3. TLS False Start와 TCP Fast Open으로 1-RTT 지원
TLS False Start 옵션은 클라이언트가 암호화된 데이터를 첫 번째 TLS 왕복 직후에 바로 보낼 수 있다. 이를 통해 TLS 기준 1-RTT, TCP 연결 기준 2-RTT로 줄일 수 있다. 이미 엣지에 강력한 암호화 스위트를 탑재하고 TLS False Start 옵션이 켜져있다.
다음 향상점은 RFC 7413에 정의된 TCP Fast Open 과정에 있다. RFC는 "Fast Open 쿠키"를 포함한 새로운 TCP 옵션을 정의했다. "Fast Open을 사용 가능한" 클라이언트가 처음 서버에 연결하면, 초기 TCP SYN 메시지에 빈 쿠키를 집어넣어서 서버가 응답에 유효한 쿠키를 넣어서 보낼 수 있게 한다. 이수 연결들에서, 클라이언트느 쿠키를 TCP SYN 메시지 안에 넣어서 데이터를 즉시 보낸다. 만약에 서버가 데이터가 무결하다고 인식하면, 데이터를 받고 앱에 보낼 것이다. TCP Fast Open이 켜져 있으면, 연결이 완성되기 전에 데이터를 보내서, 응답이 즉시 돌아올 것이다. TCP Fast Open과 TLS False Start를 조합하면, 최초 TCP 핸드 쉐이크에 키 교환이 동시에 이뤄질 것이다. 이는 HTTP 트래픽이 시작하기 전에 1-RTT만큼만 걸린다는 것을 의미한다.
7.4. TLS 1.3으로 0-RTT 지원
TCP Fast Open about:flags 설정에서 지원한다. 주소 창에서 about:flags라 치면 TCP Fast Open 설정을 관리할 수 있다. 현재는 기본값으로 꺼져 있고, 더 많은 텔레메트리 데이터를 수집하기 위해 조정할 수 있다고 한다.
다음 단계는 TLS 1.3으로 1-RTT에서 0-RTT로 향상시키는 것이다. 0-RTT를 안전하게 실현하는 것은 어렵다 - 모든 0-RTT 해법들은 클라이언트에서 키와 암호화된 데이터를 서버에서 오는 피드백을 기다리지 않고 바로 보내야 한다. 최소한, 공격자가 메시지를 잡아내고 다시 볼 수 있다는 것이다. 이 뜻은 이 기능은 굉장히 조심스럽게 사용되어야 한다는 것이다. 또한, Hello 메시지에 식별자를 평문 텍스트에 넣어서 개인 정보를 침해하는 방법이나 최초 암호화가 서버 공개키에 의존하는 방법이어서 다음 연결이 위험한 경우 같은 잠재적인 장애물들이 있다. IETF 작업 그룹은 이런 문제들에 대해 의논하고 있고, 그것들이 해결되면 이 기능이 2016년 여름에 구현될 것이고, 표준안은 몇달 뒤에 발표될 것이다.
HTTP 2.0, TLS 1.3, TCP Fast Open, TLS False Start로 엣지에 0-RTT 경험을 전달하고 있다. 또한 상호 운용 가능한 TLS 1.3 솔루션을 제공하기 위해 표준안에 참여하고 있다.
[1]
1998년 IE5에서 처음 소개된 XML을 기반으로 하는 벡터 마크업 언어이다. 이는 지금은 SVG의 존재로 인해 쓸모 없는 것이 되었기 때문에, 단지 기존 IE와의 호환성 때문에 남아 있던 것이므로 제거하는 것이다.
[2]
자바스크립트에 밀려 이젠 거의 쓰는 곳이 없을 뿐더러, 작년에는 CVE-2014-6332와 같이 지금도 다양한 Exploit Kit에서 쓰고 있는 심각한 취약점도 있었기 때문에 마찬가지로 제거한다.
[3]
ActiveX와 비슷한 측면으로 보면 된다. 이 역시 1997년에 소개된 오래된 기능으로, 브라우저가 서드파티 COM 오브젝트를 로딩하는 것인데 지금까지 다양한 확장 기능 개발에 쓰여왔다. 대표적으로
툴바를 들 수 있다.
[4]
물론, Protected Mode 같은 샌드박스가 적용된 이후의 IE 에서는 ActiveX 역시 예외 없이 낮은 Integrity Level 로 코드가 실행되기 때문에 기본적인 보안은 되지만...
[5]
OS X 애플리케이션을 개발할 경우 개발자가 샌드박스에 필요한 멀티프로세스 구조나 Broker와의 IPC 등에 대한 것을 별도로 직접 구현하거나 하지 않아도 자동으로 그렇게 동작한다.
[6]
Broker Process는 64비트인 반면 실제로 핵심적인 처리를 하는 Renderer Process들은 32비트인 경우가 많았다.
[7]
물론 쉽다고는 하나 32비트라고 해도 이를 실제로 Brute-forcing하여 공격하는 경우는 사실 거의 없다. 32비트의 경우의 수도 사실 엄청나게 많은 편이고, 브라우저 같은 경우 원격 코드 실행 시에 기회는 사실 1번 뿐이기 때문이다. 다만 Heap-spray와 같이 원하는 힙 메모리가 위치할 주소의 예측이 어느 정도 가능한 요소가 있는 경우는 예외이다. 실제로 여기서 말하는 64비트 전환시의 이점은 사실 프로세스의 Base Address에 관한 것이라기 보다 힙 메모리에 관한 내용이다.