문서의 임의 삭제는 제재 대상으로, 문서를 삭제하려면 삭제 토론을 진행해야 합니다. 문서 보기문서 삭제토론 TLS (문단 편집) === 문제점 === TLS에서 서버 및 클라이언트의 신원을 확인하는 데는 인증서가 사용되며, 인증서의 신뢰성은 인증서를 발급해 준 인증 기관에 의해 결정된다. 인증 기관이 신뢰 가능한 인증서만을 발급해 줬다면 문제가 없지만, 만약 제대로 확인되지 않은 인증서를 발급한다면 더 이상 그 인증서를 신뢰할 수가 없을 것이다. 몇몇 인증 기관에서 도메인 소유자를 확인하는 방식의 Domain Validation, 즉 DV 인증서를 발급하기 시작하였다. 이러한 인증서는 오직 발급을 요청한 자가 그 도메인의 소유자가 맞는지만을 인증하기 때문에 사실상 발급 비용만 내면 아무나 인증서를 받을 수 있다. 심지어 해커가 피싱용 도메인 narnu.wiki[* namu에서 m를 r+n으로 바꾼 것. 자세히 보지 않는 한 속기 쉽다. [[커닝]]이 나쁜 [[글꼴]]에서 자주 볼 수 있는 현상으로, 이를 일컫는 속어로 Keming이라고 한다.]을 만든 뒤, 인증 기관에 Domain Validation 인증서를 요청하면 그대로 발급된다. 도메인을 소유한 자와 인증서를 신청한 자가 동일한 사람(=해커)이기 때문. 하지만 이 피싱 사이트에 접속한 대부분의 사용자들은 HTTPS 연결이 되었기 때문에 보안이 지켜질 것이라 생각하게 된다.[* 피싱 사이트(서버)와 사용자간의 오가는 데이터는 암호화되어 보안이 지켜지나, 사이트 서버에서는 암호화된 내용을 복호화하기 때문에 연결이 된 대상이 피싱 사이트라는 점에서 로그인 정보 등 사용자 데이터에 대한 정보가 피싱 서버에 그대로 노출이 될 수 있다.] [[파일:attachment/SSL/evc.png]] 이러한 문제를 해결하기 위해 나온 것이 EV-SSL이다. EV-SSL은 공신력 있는 인증 기관에서 더욱 엄격한 심사 기준으로 발급한 Extended Validation 인증서를 사용하여 보안을 강화한 프로토콜이다. 주요 [[웹 브라우저]]를 사용해 Extended Validation 인증서를 쓰는 웹사이트에 접속하면 위와 같이 주소창에 특유의 녹색 표시가 생기며 EV-SSL 연결이 되었음을 표시했다. DV 인증서에 비해 인증서 인증 조건이 상당히 빡빡하며[* [[https://ridicorp.com/story/ev-ssl-ho|EV 인증서를 발급받기 위해 얼마나 삽질이 필요한지 알 수 있다.]] [[D-U-N-S]] 번호는 기본으로 깔고 들어가며 각종 서류도 필요하다.] 발급 비용도 도메인 인증서에 비해 몇 배 이상 비싸다. 하지만, EV-SSL 표시 여부가 대부분의 사용자에게 피싱 보호 역할을 제공하지 못한다는 UX 연구결과가 여럿 나왔고, 결국 2018년 Safari를 시작으로 2019년 크롬, 파이어폭스 등 주요 브라우저에서 EV-SSL 연결 표시를 삭제하면서[* 그냥 일반 인증서와 동일하며 EV 여부는 자물쇠를 클릭해야 알 수 있게 변경되었다.] 인기가 급격하게 식어 버렸다. 이 외에도, TLS는 망연결에서의 보안을 책임지고 있으므로, 연결된 단말기가 해킹당한 경우라면 아무리 TLS를 써도 무용지물이다.[* 공격자가 단말기를 해킹한 상황에서, 미리 TLS 통신을 이용하여 연결하다, 피해자가 TLS 접속을 시도하면 이 접속을 이용하여 공격자의 TLS 통신 재접속에 이용하는 방식등이 있다.][* HTTP/S 연결 디버깅에 사용되는 [[https://www.telerik.com/fiddler|Fiddler]]가 [[중간자 공격]]에 해당하는 기법을 사용한다. 먼저 프록시를 이용하여 모든 커넥션을 피들러로 돌린 후, 피들러가 생성한 인증서(즉 퍼블릭키)를 운영체제에 등록함으로써 클라이언트가 해당 퍼블릭키를 이용해서 암호화를 진행하도록 한다. 즉, 1. 피들러 프로그램이 프라이빗키를 들고있기 때문에 패킷의 확인/임의변조가 가능하고, 2. 퍼블릭키를 클라이언트의 인증서목록에 등록했기 때문에 클라이언트가 눈치채지 못하게 연결을 가로챌 수 있었다. 이중 2번의 경우 타 프로그램/OS의 수정이 필요하기 때문에 https 연결 디버깅을 위해서 피들러는 관리자권한/sudo를 요구한다.] 즉 연결망의 안전성과 노드의 안전성은 별개라는 의미이다. 또한 위 과정을 보면 알겠지만 [[서버]]나 [[클라이언트]]나 평문 통신에 비해 부하가 크다. 암호화 과정을 거쳐야 하기 때문. 따라서 소규모의 [[웹 사이트]]에서는 별다른 걱정 없이 HTTPS 프로토콜을 사용하지만 대규모 웹 사이트에서는 쉽게 HTTPS 프로토콜을 적용하지 못하는 경우가 많다. 이를 이용해 프론트엔드단 웹을 대상으로 [[DDoS]]라도 시도할 경우 암호화 과정 때문에 HTTPS를 사용하지 않은 웹 사이트보다 더 빨리 서버가 죽을 수도 있다. 따라서 웹 사이트 전체에 HTTPS 프로토콜을 적용하기 위해 프론트 서버를 더 늘리거나 [[Cloudflare]]의 DDoS 방어 서비스 등을 이용하는 경우가 많다. TLS는 TCP 프로토콜을 이용하므로 성능상의 불이익도 존재한다. 결국 UDP 기반의 보안 소켓인 [[DTLS]]가 이를 보완해야 한다.저장 버튼을 클릭하면 당신이 기여한 내용을 CC-BY-NC-SA 2.0 KR으로 배포하고,기여한 문서에 대한 하이퍼링크나 URL을 이용하여 저작자 표시를 하는 것으로 충분하다는 데 동의하는 것입니다.이 동의는 철회할 수 없습니다.캡챠저장미리보기