Microsoft Edge/레거시

[image]

'''엣지 레거시 '''
Edge Legacy

}}}

<colbgcolor=#3177bc> '''개발사'''

'''분류'''

'''최신 버전[1]'''

44.19041.610.0

'''엔진'''

'''EdgeHTML'''

'''플랫폼'''	데스크톱
	모바일

홈페이지

1. 개요

2. 상세

2.1. 차크라코어

2.2. 보안

2.2.1. 해킹 방어 기능

2.2.1.1. ActiveX를 포함한 각종 레거시 기술들의 지원 제거

2.2.1.2. 유니버설 윈도우 앱

2.2.1.3. AppContainer 샌드박스

2.2.1.4. 64비트 프로세스

2.2.2. 메모리 손상 방어

2.2.2.1. 제어 흐름 보호 (Control Flow Guard)

2.2.3. 바이너리 주입 보호

2.2.3.1. 모듈 코드 통합 강제 기능

2.2.4. 스마트스크린 필터를 통한 드라이브-바이 다운로드 공격 방어

2.2.4.1. 드라이브 바이 다운로드 공격

2.2.4.2. 스마트스크린 필터 개선

2.2.5. 플래시 콘텐츠 자동 일시 정지

2.2.6. Windows Hello 지원

2.2.6.1. 웹 인증: 패스워드 없이 작동하고, 2단계 인증 지원

2.2.7. TCP Fast Open, TLS False Start, TLS 1.3

2.2.7.1. TLS 1.3으로의 여정

2.2.7.2. TCP와 TLS의 전체 핸드 쉐이크

2.2.7.3. TLS False Start와 TCP Fast Open으로 1-RTT 지원

2.2.7.4. TLS 1.3으로 0-RTT 지원

3. 버전

3.1. 20.10240

3.2. 25.10586

3.2.1. EdgeHTML 13[2]의 기능 업데이트

3.2.2. 차크라 엔진 기능 업데이트

3.2.3. 지원 플랫폼 확장

3.2.4. 새로운 사용자 기능들

3.3. 38.14393

3.3.1. 마이크로소프트 확장 기능

3.3.2. 접근성 기능 강화

3.3.3. 새로운 기능

3.3.4. 효율, 보안, 성능, 호환성 강화

3.3.5. 기업용 기능

3.4. 40.15063

3.5. 41.16299

3.6. 42.17134

3.7. 44.17763

3.8. 44.18362

3.9. 44.19041

4. 장단점들

4.1. 장점

4.2. 단점

5. 점유율

5.1. 대한민국에서의 상황

6. 단종

7. 기타

[clearfix]

1. 개요

'''엣지 레거시'''(Edge Legacy)는 EdgeHTML 엔진 기반의 웹 브라우저이다.

2. 상세

Edge는 마이크로소프트가 현대 웹 디자인과의 호환성을 극대화하기 위해 기존 인터넷 익스플로러에 사용되던 렌더링 엔진인 Trident(mshtml.dll)를 '''하위호환을 고려하지 않고''' 바닥부터 개조하여 만들어낸 렌더링 엔진인 EdgeHTML(edgehtml.dll)을 기반으로 만들어진 새로운 웹 브라우저다.
[image] [image]
간단하게 말하자면 '''엣지는 인터넷 익스플로러와 완전히 다른 브라우저다.''' 비유를 굳이 하자면, 집을 이사하지는 않았지만 안에 있는 각종 물건과 가구와 붙박이장까지 죄다 빼버리고 인테리어를 처음부터 다시 짜는 수준의 변화가 있었다. 그 변화의 폭이 어느 정도인지를 확인하려면 위의 그림을 확인하면 좋다. IE 11은 11뿐만이 아니라 10, 9, 8, 7[3], 심지어 5.x까지 지원하기 위한 하위 호환 코드들을 그대로 가지고 가고 있다. 하지만 엣지는 이 하위 호환을 위한 코드를 전부 날려버리고, 심지어 바로 이전 브라우저인 IE 11과의 호환을 위한 코드까지 남김없이 뜯어낸 뒤 WebKit 또는 Gecko[4]와 비슷한 현대적인 방식으로 렌더링을 하고, 심지어 WebKit 전용 API까지 다수 끌어오면서 웹 표준을 따라 최근 만들어진 사이트들을 표시할 때 깨지거나 오류가 나는 상황을 최소화하는 것을 목적으로 하고 있다.
이것은 곧 MS가 드디어 '''ActiveX를 버린 브라우저'''를 만들었다는 뜻이기도 하다. ActiveX를 위시한 IE 6~8 방식의 웹 디자인은 해외에서도 그 문제가 심각하기 때문이다. 특히 기업용 웹페이지 및 소프트웨어(ERP 등)가 IE 6~8을 요구하는 경우가 많다고 하며, 이런 부분 때문에 MS가 함부로 IE 6~8 코드나 ActiveX를 버리지 못한 측면이 크다. IE 9 이래로 IE는 이 시절의 IE에 비하면 훨씬 더 나아졌고 상당 부분 웹 표준을 따라가고 있지만, 아직 기본적인 원리는 IE 5.x 내지는 IE 6~8 시절을 따라가고 있어 종종 오류가 나기도 했고, 반대로 웹페이지 쪽에서 사용자의 브라우저를 IE로 인식하는 바람에 웹 표준을 지키는 IE 10이나 IE 11을 사용함에도 불구하고 IE 6~8 방식으로 코드를 보내주면서 문제가 생기기도 했었다. Edge는 이를 막기 위해 레거시 코드를 통째로 날리고, 오히려 WebKit과의 호환성을 증대하는 방향[5]으로 하여 최신의 방식으로만 코드를 받고 표기하는 것을 목표로 한다.
앞서 살펴본 바와 같이 엣지는 완전히 새로운 브라우저이기 때문에, ActiveX로 떡칠되어 있는 온라인 뱅킹이나 인강 등의 서비스를 전혀 사용할 수 없다. 때문에 IE 11을 남겨두는 방식으로 호환성 문제를 간단하게 해결하였다. 아직 IE의 구식 코드를 필요로 하는 사이트가 많고, 이런 사이트들이 많을 수록 호환성 문제로 업그레이드하지 않을 사람들이 많아질 것을 MS가 모를리가 없기 때문에, Windows 10에서도 IE 11은 여전히 있다. 다만 Windows 10의 기본 브라우저는 Edge이며, IE 11은 어디까지나 레거시 프로그램으로서 시작 메뉴의 보조프로그램 폴더로 들어가야 사용할 수 있다고 한다.
따라서 Edge가 차기 웹 브라우저로서 꾸준히 업데이트될 예정인 것과는 달리, IE는 더 이상의 기능 변경 및 개선 없이 보안 패치만 해줄 예정이다. 레거시 지원을 위해 남아있기는 하지만.
일단 Windows 10의 기술지원이 계속되는 한 IE 11이 보안 패치라는 이름의 호흡기는 계속 붙들고 있을 것이다. 인터넷 익스플로러 지원 주기 정책 faq에 따르면 어떤 윈도우 버전에서 이용가능한 인터넷 익스플로러의 가장 최근판은 그 윈도 버전의 지원중단 기간까지 사후지원(이미 말했듯, 보안 문제 해결 정도에 그친다)을 해 주는데, Windows 10에 들어서서 새로운 Windows를 개발하는 대신 macOS 비슷하게 Windows 10의 신규 버전을 지속적으로 업데이트하는 것으로 정책이 바뀌었다. 레드스톤 같은 업데이트가 지속되는 한 Windows 10의 지원 기간은 사실상 무한정이고, 그동안 IE 11에 대한 지원도 무한히 계속된다는 것이다.
Edge가 Windows 10의 '''기본 브라우저'''라고 하지만, 사실 Windows 10의 Enterprise LTSB/LTSC 에디션에는 Edge가 제공되지 않는다. Enterprise LTSB/LTSC 에디션은 기업체 등 '시스템의 안정성을 고도로 유지해야 되는 곳'을 겨냥한 것으로 꼭 필요한 보안 패치 이외에는 신규 업데이트는 거의 하지 않으며, 이것이 빠른 업데이트와 신속한 변화를 하는 엣지 브라우저와 어울리지 않기 때문에 LTSB/LTSC의 기본 브라우저는 IE 11이다.ZDnet 이런 사용자들 때문이라도 IE를 완전히 버릴 수는 없는 상황.
'''하지만, Windows 10의 특정 업데이트 버전에서 인터넷 익스플로러가 제거될 가능성도 배제할 수 없다.''' 앞에서 거론된 macOS의 경우에도 초창기의 기본 브라우저는 믿을 수 없게도 Internet Explorer였다. 그 이후로 20년에 가까운 시간을 macOS 10 버전에서 여전히 뭉개고 있었지만 기본 브라우저는 Safari로 바뀌었고, Internet Explorer는 서드파티 브라우저로 밀려난 뒤 지금은 완전히 사라져버렸다.
여담으로 Windows 7/Windows 8.1의 IE 11과 Windows 10의 IE 11은 약간의 차이가 있다. 예를 들어 8.1의 경우 '소스 보기'를 할 때 소스 보기 창이 열리지만, 10의 경우 개발자 도구가 열린다. 또한 8.1의 IE 11과는 달리 우측 메뉴에 스마일 버튼이 있는데 MS에게 피드백을 보내는 기능이다. 또한 HTTP/2와 TLS 1.3(21H1 이후)도 Windows 10의 IE 11에서만 지원하는데, 사실 이는 시스템 라이브러리를 같이 사용하기 때문이다.

2.1. 차크라코어

차크라코어 GitHub 페이지
사트야 나델라 체제 이래로 마이크로소프트가 꽤 많은 서비스들을 오픈소스로 전환하기 시작했고, EdgeHTML 엔진 역시 협력사의 커밋을 받는 등 상당히 개방적인 태도를 보이고 있어서, 한동안 EdgeHTML 및 엣지 브라우저가 오픈소스로 전환할 것이라는 관측이 있었다. 엣지 팀에서는 당장은 이들을 오픈소스로 전환할 계획은 없다고 밝혔으나, 결국 2015년 12월 5일에 IE 및 엣지의 자바스크립트 엔진인 차크라를 오픈소스로 전환한다는 발표가 있었다.
[image]
아직 윈도우가 오픈소스가 아니기 때문에 엔진에서 일부를 잘라낸 후 "차크라코어"라는 이름을 붙여 공개하기는 했지만, 위의 그림을 보면 사실상 엔진의 대부분을 공개했다. 브라우저 및 유니버설 윈도우 플랫폼 관련 부분 및 구형 API의 연결 부분만 잘라냈을 뿐, 브라우저의 내부 구조 및 여러 활용 방법과 관련이 있는 대부분의 API들이 전부 공개되었기 때문이다. 2016년 1월 현재 우선 과제 중 하나는 무려 리눅스 포팅으로, 우분투 리눅스 15.04 x64 버전에 차크라코어를 옮기는 것을 목적으로 하고 있다.
본인의 개발 실력과 영어 능력이 뒷받침 된다는 전제 하에 .NET과 함께 좋은 마이크로소프트 입사 도구라는 말이 있다. 비교적 새롭게 오픈 소스로 공개된 기획이기 때문에 손을 댈 여지도 많고, 개발 커뮤니티의 분위기 역시 비교적 우호적이기 때문에, 꾸준하게 의미 있는 커밋을 할 수 있다면 엣지 팀에서 먼저 관심을 가지고 입사원서도 쓰지 않았는데 스카웃 해 갈 수도 있다는 것이다.

2.2. 보안

보안에 있을 때에는 Internet Explorer 11에서도 10보다 많은 것이 향상되었던 것처럼 Microsoft의 최근 몇 년간의 행보는, Memory Corruption 류의 취약점을 활용하는 해킹에 대한 방어도 옛날보다 꽤나 적극적으로 하는 것을 보여주고 있다. 이번 Edge 브라우저에서도 역시 새로운 보안 기능이 많이 추가되었다. 아래의 내용들은 모두 여기 에서 공식적으로 발표된 내용에 기반한 것이다.

2.2.1. 해킹 방어 기능

2.2.1.1. ActiveX를 포함한 각종 레거시 기술들의 지원 제거

이 문서에서도 줄기차게 언급되고 있고, 위 출처에서도 가장 먼저 나오는 내용인 만큼 그 중요성이 어느 정도인지는 굳이 얘기할 필요가 없을 것이다. 정확히 말하자면, 단지 ActiveX의 제거뿐만이 아니라 VML(Vector Markup Language)[6], VBScript[7], BHO(Browser Helper Objects)[8], ActiveX를 모두 제거한다는 것이다. ActiveX의 경우, 이를 제거하는 대신 더 보안성이 향상되고 HTML/자바스크립트 기반의 다른 확장 기능 모델을 추가한다는 내용이다. 아직 발표되지는 않았으나 오래 안가서 소개될 것이라 생각된다.
이는 IE에서만 지원하는 오래된 것들을 모두 제거하고, 보안성에 있어서도 문제가 되어 왔던 것들을 제거함으로서 상당히 큰 발전이라고 할 수 있다. 구글의 경우에도 NaCl(Native Client) 등의 고급 기술을 개발해서 샌드박스 내에서 서드파티 바이너리(확장기능 등)를 실행하는 것을 어렵사리 구현하고 있는데, ActiveX와 같이 아무런 부가적인 보안 요소 없이[9] 그대로 로컬 액세스 권한을 주는 것은 지금 시대에서는 심각하게 뒤떨어진 것이다. 이를 마이크로소프트도 예전부터 인식하고 있었으나 호환성으로 인해 쉽게 제거하지 못하였는데 이제 엣지라는 별개의 브라우저로 개발하게 되면서 이를 모두 제거할 수 있는 일종의 기회를 얻었다고 볼 수 있다.

2.2.1.2. 유니버설 윈도우 앱

엣지는 유니버설 윈도우 앱 기반으로 개발되었다. 이는 유니버설 윈도우 플랫폼(UWP) 기반으로 동작하는 애플리케이션으로, Windows 8에서 처음 소개된 것이다. 이름 그대로 모바일 기기와 데스크톱 PC 등을 모두 아우르는 앱을 개발하는 것인데, 엣지는 이 유니버설 앱으로 개발되었다. 언뜻 보면 이는 보안과는 별 관계는 없어 보이지만, 유니버설 윈도우 앱의 경우 애플리케이션에서 구현을 따로 하지 않아도 기본적으로 적용되는 보안 모델이 별개로 존재한다. 쉽게 말해서 마치 OS X 처럼 애플리케이션이 동작할 때 기본으로 샌드박스가 한 층 추가된다고 보면 된다.[10] 실제로 엣지를 실행하고 처음 프로세스를 확인해 보면 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에 와서야 소개했기 때문에 아직 적용이 늦다는 차이뿐이다. 물론 아직까지도 윈도우는 이렇게 개발하는 것이 기본이 아니기 때문에 대부분의 응용 프로그램은 샌드박스 내에서 안전하게 동작하는 것이 아니라 지금까지처럼 '날것'으로 실행될 것이다.

2.2.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 같은 소프트웨어도 자체적으로 샌드박스를 구현하고 있을 정도다.

2.2.1.4. 64비트 프로세스

인터넷 익스플로러도 64비트 운영체제에서 64비트로 동작하는 것을 지원하였으나, 옵션으로 64비트 프로세스 사용 설정을 따로 해야 하는 경우가 있었다.[11][12] 엣지는 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비트 주소 공간에서는 주소가 위치할 수 있는 경우의 수도 그 만큼 작으므로 추측이 비교적 쉽다.[13] 그러나 64비트의 경우 2^64 라는 어마어마한 주소 공간을 사용할 수 있고(물론 x86_64(x64) 아키텍쳐에서는 2^48 만 사용하지만 이 역시 32비트에 비하면 엄청나다.) 이는 사실상 추측이 불가능한 entropy로 ASLR을 적용할 수 있다.

2.2.2. 메모리 손상 방어

2.2.2.1. 제어 흐름 보호 (Control Flow Guard)

Visual Studio 2015에 적용된 기능으로, 컴파일시 포인터 기반 간접 점프를 확인하는 기능이다. 메모리 손상 취약점의 목표는 해커가 원래 프로그램 코드 중 간접 점프 코드를 통해 자신이 원하는 새로 넣은 코드로 점프해 악성코드를 실행하는 것이다. 제어 흐름 보호는 이런 점프 목적지를 원래 코드 함수 시작점으로 제한해 메모리 손상 취약점을 방어해 해커의 의도를 무력화시키려는 것이다. 엣지를 컴파일할 때 이 기능을 넣고 컴파일했다고 한다. IE에도 적용된 기능이다.

2.2.3. 바이너리 주입 보호

2.2.3.1. 모듈 코드 통합 강제 기능

EdgeHTML 13부터 엣지에서 로드하는 모든 동적 라이브러리는 WHQL 인증을 받아야 한다. 여러분이 설치하는 거의 대부분의 드라이버는 마이크로소프트에서 WHQL 인증을 받는데, 이는 대부분 드라이버가 관리자 권한을 가지기 때문이다. 이것을 똑같이 브라우저 동적 라이브러리에도 적용시킨다고 보면 된다. 엣지는 WHQL 인증을 받은 라이브러리만 로드하고, 아닌 라이브러리들은 막는다. 이 기능을 프로세스 단에서 할 수도 있고, 커널 단에서 할 수 있는데, 프로세스 단에서 하면 프로세스가 감염됐을 때 기능이 작동하지 않을 수 있다는 단점이 있다. 그래서 윈도우 커널 단에서 라이브러리를 확인해 프로세스가 감염되어도 커널에서 프로세스를 강제로 꺼버릴 수 있고, 프로세스에서 커널에 접근하기도 힘들어 이 기능을 유지할 수 있다.

2.2.4. 스마트스크린 필터를 통한 드라이브-바이 다운로드 공격 방어

2.2.4.1. 드라이브 바이 다운로드 공격

스마트스크린 필터는 URL 평판과 앱 평판을 기반하여 악성 URL을 차단하고, 악성 프로그램을 받지 못하게 하는 기능이다. 그래서 많은 악성 웹사이트에 사용자들의 접근을 막아 브라우저를 안전하게 한 기능이다. 그래서 드라이브-바이 다운로드(Drive-By download) 공격이라는 것이 생겼는데, 이는 기존의 잘 알려진 웹사이트를 해킹해 자신의 악성코드를 사이트에 올리고, 그 웹사이트에 접속한 사용자들을 취약점을 통해 감염시키는 공격이다. 이렇게 하면 평판 기반 방어는 그 사이트가 잘 알려진 웹사이트이기 때문에 성공적으로 방어할 수 없다. 이런 드라이브-바이 다운로드 공격은 보통 취약점 킷(익스플로잇 킷; 여러 취약점들을 동시에 노리는 코드)을 통해 이뤄지며, 많은 사용자들이 모든 프로그램을 제때 업데이트하지 않기 때문에 성공할 확률이 높다. 특히 현재 추세가 아래와 같이 이런 취약점 킷 공격이 많아지고 있는 추세라 사용자들이 더욱 위험해질 수 있다.
[image]
그래서 윈도우 디펜더, 엣지, 인터넷 익스플로러, 빙, EMET 등의 툴들을 통해 수집된 악성 신호들을 실시간으로 스마트스크린 필터에 적용해 이런 취약점 킷 공격을 방어하는 것이다. 실제로, 이 기능을 통해 HanJuan EK라는 취약점 킷이 디펜더와 EMET에 잡히자마자 스마트스크린 필터에 등록되고, 조사를 통해 이 취약점 킷이 어도비 플래시 플레이어 제로데이 취약점을 이용한다는 것을 알아냈다. 이 취약점은 CVE-2015-0313로 명명되었다.

2.2.4.2. 스마트스크린 필터 개선

이런 드라이브-바이 다운로드 공격을 방어하기 위해서는 이런 공격들이 웹페이지가 렌더링 되기 전에 탐지되고 차단되어야 한다. 이는 브라우저 성능에도 미칠 수 있기 때문에, 스마트스크린 필터는 작은 캐쉬 파일에 악성 파일을 기록하고, 그걸 기반으로 드라이브-바이 다운로드 공격을 방어한다. 새로운 악성코드가 계속 나오기 때문에, 당연히 이 캐쉬 파일은 주기적으로 업데이트된다.
URL이 악성으로 판명되면 다음과 같이 대문짝만하게 웹페이지가 위험하다고 알려준다.
[image]
또한, 프레임 단위 경고 기능을 추가해, 위험한 광고 프레임만 차단하고 나머지 정상적인 부분들은 렌더링하는 기능도 추가했다. 그래서 일부만 문제가 있어도 전체 내용을 보지 못하던 경험을 개선했다고 한다.
[image]
만약에 스마트스크린 필터가 오탐했다고 생각되면 자세한 정보 링크를 통해 경고 페이지를 확장해 우회할 수 있지만 추천하지는 않는다. 프레임 단위로 차단되었을 경우에는 안전하지 않은 콘텐츠 뱃지를 눌러서 똑같이 우회할 수 있다. 그리고 기존의 스마트스크린 설정과 컨트롤들(그룹 정책 포함)은 새 드라이브-바이 다운로드 공격 보호 기능을 자동으로 추가했다.

2.2.5. 플래시 콘텐츠 자동 일시 정지

안전하고 좋은 성능과 안정적인 브라우저를 제공하기 위해 플래시의 리소스와 전력을 조정했다. 1주년 업데이트부터 웹페이지에서 중요하지 않은 플래시 콘텐츠는 자동으로 일시정지된다.
애니메이션이나 광고같은 주변부 콘텐츠는 유저가 콘텐츠를 재생하도록 클릭을 하지 않는 이상 일시정지된 상태로 있을 것이다. 이로 인해 전체 콘텐츠를 재생하는 것 보다 전력 소모가 감소하고 성능이 향상될 것이다. 비디오나 게임같은 페이지 중심에 있는 콘텐츠는 일시정지되지 않는다.
또한 웹 표준의 기능을 더더욱 강화시켜 더 안전하고 성능이 향상된 경험을 플래시 없이 사이트들이 제공할 수 있도록 노력한다고 한다. 웹 표준을 사용할 때 배터리 수명이 늘어나고 CPU 부하와 메모리 소모가 감소한다고 한다. 개발자들은 웹표준을 통해 모든 브라우저와 모바일 같은 플래시를 쓸 수 없는 장치에서 사이트들이 잘 작동하게 만들 수 있다.

2.2.6. Windows Hello 지원

빌드 2016에서 마이크로소프트 엣지가 전 세계에서 처음으로 안전하고 쉽게 웹에서 인증을 할 수 있게 Windows Hello를 지원하는 브라우저가 될 것이라고 발표되었다. 이는 웹 인증 (이전에는 FIDO 2.0 Web API로 불림)의 초기 구현에 의해 작동하고, FIDO Alliance와 W3C 웹 인증 작업 그룹에서 이들 API를 표준화하기 위해 작업하고 있다고 한다. 테스트 드라이브 데모에서 이를 체험해볼 수 있다.
기존 패스워드에 많은 문제점들이 있는데, 많은 사람들이 모든 사이트들에 대해 강력하고 전부 다 다른 패스워드를 쓰지 않는다는 것이다. 보통 기억하기 쉽게 만들거나 모든 계정들에 대해 같은 패스워드를 사용한다. 또, 패스워드를 바꾸더라도 "123456"이나 "password" 같은 쉬운걸로 바꾸는 경우가 많다. 해커들은 보통 사회 공학적 기법, 피싱, 키로깅 기법으로 개인 컴퓨터에서 패스워드를 빼내게나, 패스워드를 저장한 사이트를 장악해서 빼내는 경우가 많다. 만약에 패스워드가 여러 사이트에서 동시에 사용된다면, 한 계정만 해킹해도 다른 계정들도 위험해진다.
하지만 이 기술을 통해 인증을 위해 유저가 더 이상 패스워드를 기억하지 않아도 되고, 서버가 저장하지 않아도 된다. 웹 인증과 Windows Hello를 결합해서 생체인식 기술과 비대칭 암호화를 통해 구현한다고 한다. 유저를 인증하기 위해서, 서버가 브라우저에 평문 텍스트 문구을 먼저 보낸다. 엣지가 유저를 Windows Hello로 식별할 수 있다면, 시스템이 유저에 할당된 개인키로 문구에 서명하고 인증서를 서버로 보낸다. 만약에 서버가 이 인증서를 공개 키로 인증서를 확인할 수 있다면, 유저에서 온 것을 확인할 수 있고, 유저를 안전하게 인증할 수 있다.
[image]
이 키들은 강력한 계정들을 제공할 뿐만 아니라 추측할 수 없고, 원본 외에서 다시 사용될 수 없다. 공개키는 그 자체로 의미 없고, 개인키는 공유되지 않기 때문이다. Windows Hello로 더 좋은 유저 경험을 제공할 뿐만 아니라, 패스워드 추측, 피싱, 키로깅, 서버 데이터베이스 공격으로 계정을 탈취할 수 없다.

2.2.6.1. 웹 인증: 패스워드 없이 작동하고, 2단계 인증 지원

FIDO Alliance에 참가해 웹에서 패스워드를 제거하고 강력한 계정을 생성할 수 있도록 여러 기업들과 같이 작업을 하고 있다고 한다. FIDO Alliance의 주 목표는 이런 인터페이스들을 표준화해, 웹사이트들이 Windows Hello와 다른 생체 인식 기술들을 모든 브라우저에서 사용할 수 있게 하는 것이다. FIDO Alliance는 FIDO 2.0 제안을 W3C에 제출했고, 새로 생긴 웹 인증 작업 그룹은 이들 API를 W3C 웹 인증 표준안에 넣기 위해 이들 API를 표준화하고 있다.
[image]
웹 인증 표준안은 다음 2가지 인증 시나리오를 정의하고 있다: 패스워드 없이 인증, 2단계 인증. 패스워드 없이 인증하는 경우는, 유저가 웹페이지에 로그인하기 위해 유저 이름이나 패스워드 없이 - Windows Hello만으로 로그인할 수 있다. 2단계 인증의 경우는, 유저가 유저 이름과 패스워드로 로그인하지만, Windows Hello가 2단계 인증을 해 전체적인 인증을 강력하게 할 수 있다.
전통적인 패스워드 인증은 유저가 패스워드를 생성하고 서버에 알려줘서 서버가 패스워드를 해시화해 저장한다. 유저, 또는 패스워드를 취득한 공걱자는 똑같은 패스워드를 어느 장치에서나 서버에 인증하기 위해 쓸 수 있다. 하지만 웹 인증 표준안은 비대칭 키 인증을 사용한다. 비대칭 키 인증에서는, 유저 컴퓨터가 비밀 키와 공개 키로 구성된 강력한 암호화 키 쌍를 생성해, 공개 키를 서버에 제공하고, 개인 키를 컴퓨터의 TPM 같은 전용 하드웨어에 저장해 컴퓨터에서 다른 곳으로 이동할 수 없게 한다. 이 방식은 클라이언트와 서버 둘 다에 대한 공격을 방어할 수 있다 - 다른 곳에서 공격자가 인증하려는 클라이언트 공격은 성립되지 않고, 서버를 공격해도 공개키 리스트만 얻을 수 있다.
마이크로소프트 엣지는 현재 웹 인증 스펙의 초기 구현을 지원한다 - 사실, 최근 작업안이 업데이트되어 현재 구현을 벗어나있고, 표준안 프로세스를 지나면서 스펙이 계속 변경될 것이다. 그래서 현재 API들은 ms-prefix가 붙어있고, 이들 API들은 미래에 바뀔 가능성이 높다. 그래서 표준안이 만들어질 때까지 API들을 업데이트해 변경점을 제대로 지원할 것이다.
웹 인증 API들은 매우 간단한다 - 두 메서드: window.webauthn.makeCredential와 window.webauthn.getAssertion로 구현된다. 이를 지원하려면 서버와 클라이언트 모두 수정을 해야 한다.
1903 업데이트를 위한 Insider Preview (Slow/Fast)에서 Windows Hello를 통한 Microsoft Account 로그인을 지원한다. Edge에서 Microsoft Account 접속 후 설정하면 된다. 피드백 허브 퀘스트

2.2.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에서의 버그는 Adguard측의 업데이트로 픽스되었다.

2.2.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만 줄여도 더 나은 웹서핑을 즐길 수 있다는 것을 고려해보면 된다.

2.2.7.2. TCP와 TLS의 전체 핸드 쉐이크

현재 TCP와 TLS 표준은 서버에 3번 왕복해야 한다 (3-RTT). 첫 번째 왕복은 TCP 연결 인수를 교환하기 위해 필요하다. 두 번째 왕복에서, 클라이언트와 서버가 연결의 키와 인수를 교환하기 위해 클라이언트 Hello와 서버 Hello로 시작하는 TLS 메시지를 교환한다. 마지막 왕복에서는 TLS 핸드 쉐이크 무결성을 확인하기 위해 클라이언트와 서버 완료 메시지를 교환한다.
[image]

2.2.7.3. TLS False Start와 TCP Fast Open으로 1-RTT 지원

TLS False Start 옵션은 클라이언트가 암호화된 데이터를 첫 번째 TLS 왕복 직후에 바로 보낼 수 있다. 이를 통해 TLS 기준 1-RTT, TCP 연결 기준 2-RTT로 줄일 수 있다. 이미 엣지에 강력한 암호화 스위트를 탑재하고 TLS False Start 옵션이 켜져있다.
[image]
다음 향상점은 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만큼만 걸린다는 것을 의미한다.
[image]

2.2.7.4. TLS 1.3으로 0-RTT 지원

TCP Fast Open about:flags 설정에서 지원한다. 주소 창에서 about:flags라 치면 TCP Fast Open 설정을 관리할 수 있다. 현재는 기본값으로 꺼져 있고, 더 많은 텔레메트리 데이터를 수집하기 위해 조정할 수 있다고 한다.
[image]
다음 단계는 TLS 1.3으로 1-RTT에서 0-RTT로 향상시키는 것이다. 0-RTT를 안전하게 실현하는 것은 어렵다 - 모든 0-RTT 해법들은 클라이언트에서 키와 암호화된 데이터를 서버에서 오는 피드백을 기다리지 않고 바로 보내야 한다. 최소한, 공격자가 메시지를 잡아내고 다시 볼 수 있다는 것이다. 이 뜻은 이 기능은 굉장히 조심스럽게 사용되어야 한다는 것이다. 또한, Hello 메시지에 식별자를 평문 텍스트에 넣어서 개인 정보를 침해하는 방법이나 최초 암호화가 서버 공개키에 의존하는 방법이어서 다음 연결이 위험한 경우 같은 잠재적인 장애물들이 있다. IETF 작업 그룹은 이런 문제들에 대해 의논하고 있고, 그것들이 해결되면 이 기능이 2016년 여름에 구현될 것이고, 표준안은 몇달 뒤에 발표될 것이다.
[image]
HTTP/2, TLS 1.3, TCP Fast Open, TLS False Start로 엣지에 0-RTT 경험을 전달하고 있다. 또한 상호 운용 가능한 TLS 1.3 솔루션을 제공하기 위해 표준안에 참여하고 있다.

3. 버전

3.1. 20.10240

2015년 3월 30일에 테크니컬 프리뷰의 10049 빌드를 통해 엣지가 처음으로 대중에 공개되었다. 발표회에서 밝혔던 필기 기능, 리딩 리스트 기능, 코타나 연동 등의 기능들이 전부 사용 가능한 상태로 풀렸다. 첫 번째 정식 버전인 20.10240.16384.0은 7월 29일에 윈도우 10과 함께 공개되었다.

원노트 연동

웹페이지에 바로 필기를 할 수 있고, 필기 후 원노트로 다른 사람들과 원노트로 공유할 수 있다.

읽기 뷰

웹페이지의 메뉴, 광고 등을 다 치워버리고 내용만 보여주며, 레이아웃 최적화를 통해 쉽게 읽을 수 있게 한다. 읽기 리스트에 웹페이지나 PDF 파일을 저장해 쉽게 볼 수 있고, 구성할 수 있다. 맥 OS나 iOS의 읽기 목록을 생각하면 편하다.

쉽게 찾기

주소 바를 향상시켜, 추천 웹페이지를 보여주고, 주소바에 날씨, 증권, 정의, 계산 등을 할 수 있다.

[image]

코타나 연동

엣지에서 코타나를 통해 바로 예약을 하거나, 리뷰를 웹페이지를 벗어나지 않고 할 수 있고, 모르는 단어를 하이라이트 하면 설명해준다.

3.2. 25.10586

두번째 정식 버전인 25.10586 버전이 2015년 11월 12일부터 Windows 10 TH2 업데이트와 함께 배포되었다. ObjectRTC 지원, 탭 미리보기 기능, 미디어 캐스팅 기능 등의 향상점이 있다.

3.2.1. EdgeHTML 13[14]
레이아웃 엔진 버전은 13, 브라우저 버전은 25
의 기능 업데이트

HTML 기능을 강화했다. 다음 사진은 HTML5Test라는 곳에서 즉정한 HTML5 표준 지원 정도를 나타내고 있는데, 7월에 나온 EdgeHTML 12보다 56점이 상승했다.
[image]

웹 컴포넌트