편집 필터 기록

'[[분류:네트워크]][[분류:인증]] [[파일:리브레 SSL.png|thumb|[[리브레 위키]]에 SSL 연결됨]] * Secure Socket Layer == 개요 == [[HTTP]] 연결을 암호화해 신뢰성을 보장하고, 보안을 지켜내는 방법. 이 방법으로 연결하는 HTTP 연결은 HTTPS 연결이라고 부른다. [[비대칭 암호화]](공개키 암호화) 방식을 이용해 [[웹 브라우저]]가 "이 서버에서 온 것이 맞는가?"를 판단하여 초보적인 [[중간자 공격]](MITM)을 예방할 수 있다. HTTPS 뿐만 아니라 [[SSH]]/SFTP, [[FTP]]S, [[WEBDAV]]S 등 중간자 공격을 예방하고자 하는 곳이면 쓰인다. 넷스케이프에서 SSL(Secure Socket Layer)이란 이름으로 상용화되었으며, TLS(Transport Layer Security)라는 이름으로 표준에 채택되었으나 선점효과로 SSL 또는 TLS/SSL이라고 불린다. == 인증서 == SSL 연결에는 인증서가 쓰인다. 인증서의 권위에 따라 몇 가지로 구분된다. * DV (Domain Validation) : "이 도메인에 맞는 웹서버임을 인증"하는 인증서이다. 중간자 공격 방지에는 충분하지만, 도메인 소유만 인증되면 발급되기 때문에 허위 도메인에 발급된 인증서들이 문제가 되었다. * OV (Orgazination Validation) : "이 기관의 웹서버가 맞습니다"라는 인증서. 이걸 받으려면 실제 사업자라는 인증이 필요하다. * EV (Extended Validation) : OV의 강화판. 인증 기관에서도 철저하게 관리하며 이걸 받은 사이트에 접속하면 웹 브라우저가 [[파비콘]] 자리에 소유자 이름을 띄워줘 확실한 표식을 제공한다. 어떤 느낌인지 궁금하면 [https://www.naver.com/ 네이버 메인]과 [https://nid.naver.com/user2/help/idInquiry.nhn?menu=idinquiry 네이버 아이디 찾기]를 비교해보라. 개인 사이트 정도면 자체 서명 인증서를 사용해도 무방하나, SOHO 이상은 신뢰를 보장받기 위해 공신력 있는 인증기관(CA)의 서명을 받은 인증서를 사용한다. CA의 1차 인증서는 브라우저에 내장되어 제공되기 때문에 누군가 의도적으로 신뢰되지 않는 CA를 설치하지 않는 이상 수상한 인증서들은 거진 걸러진다. 인증기관이 허위 인증서를 발급하는 등 신뢰해주기 어렵다고 판단되면 웹 브라우저 개발주체들은 해당 인증기관의 Root CA 서명을 제거하여 인증서의 신뢰 판별을 중단하고, 신뢰를 잃은 인증기관의 인증서는 '안전하지 않음' 상태가 되거나 웹 브라우저에서 연결을 거부한다. 특히 [[모질라 파이어폭스]]가 까다롭다. 인증기관의 서명이 탑재되지 않은 대표적인 사례는 다음과 같다. * [[한국인터넷진흥원]](KISA) *: 인증서 관리를 제대로 하지 않아 모질라 파이어폭스에 자신들의 CA 서명을 탑재하지 못하고 있다.<ref>[https://bugzilla.mozilla.org/show_bug.cgi?id=335197 Add KISA root CA Certificate], Bugzilla, 2016.04.23</ref> 또한 행정, 교육 등의 목적으로 타 부처가 별도로 하위인증기관을 두고 있는 데, 이들은 제3자 인증을 받지 못해서 신뢰를 받지 못한다. 2018년에는 지방교육청에서 임의로 만들면서 행정 편의만 생각하다가 국제망신을 당하기도 했다.<ref>[http://www.boannews.com/media/view.asp?idx=68221 행정전자서명, 시도교육청의 무분별한 발급으로 보안성 훼손], 보안뉴스, 2018.04.06.</ref> * [[StartCom]] *: 중국 회사에 인수된 이후 허위 인증서 발급이 발각되어 구글 크롬과 모질라 파이어폭스에서 CA 서명이 빠졌다. DV는 무료로 발급하기 때문에 많은 수가 발급되어 있다.<ref>[http://www.zdnet.co.kr/news/news_view.asp?artice_id=20161027101007&type=det&re= 파이어폭스서 中 치후360 자회사 인증서 차단], ZDnet, 2016.10.27</ref> * [[시만텍]](Symantac) *: 2016년 ~ 2017년간 허위 인증서 발급이 탄로나 신뢰 상실 위기에 놓였다. 구글과 시만텍 간의 진실게임이 지속되고 있으며, 시만텍은 대한민국 등록대행 파트너인 [[한국전자인증]]이 무단 발급한 127개만 인정했으나<ref>[https://knowledge.symantec.com/support/ssl-certificates-support/index?page=content&id=INFO4154 Symantec Certificate Problem Report March 6 , 2017 (Updated)], Symantac, 2017.01.26</ref>, 구글은 3만개가 넘는 인증서가 허위 발급되었다고 주장했다.<ref>[http://www.zdnet.co.kr/news/news_view.asp?artice_id=20170326032010&type=det&re= 구글, 시만텍 인증서 보안수준 평가절하], ZDnet, 2017.03.26</ref> 구글 크롬이 시만텍의 CA 자격을 격하함에 따라 시만텍은 사업을 포기하고 타사에 매각했다.<ref>[http://www.dt.co.kr/contents.html?article_no=2017080302109960041001 시만텍, 웹 인증서 사업부문 사모투자사에 매각], 디지털타임스, 2017.08.03.</ref> == 무료 SSL 적용 == 날이 갈수록 SSL의 필요성이 증대됨에 따라, 개인 [[VPS]]나 [[홈 서버]]에 SSL을 적용하는 사람들이 있다. 도메인 소유만 확인하는 DV의 발급이 까다롭지 않고 저렴한 것도 있지만, 무료로 DV를 발급해주는 프로그램이 있기 때문이다. StartSSL과 Let's Encrypt 2개가 있다. StartSSL은 위에서 부정발급 사례로 소개되었던 StartCom의 프로그램이므로 이쪽 사용을 권장하진 않는다. 다만 Let's Encrypt보다 발급절차가 쉽고 인증 기간이 1년에서 최대 3년으로 길게 나오기 때문에 Let's Encrypt를 적용하기 정말 어려운 상황이라면 사용하는 수단 정도로 생각하면 좋다. Let's Encrypt는 자체적인 Root CA를 가지고 있는 프로젝트이지만, 웹 브라우저 호환성을 위해 IdenTrust의 협조를 받고 있다. 이 프로젝트의 특징은 리눅스/유닉스 서버에서 직접 인증 절차를 거쳐야 한다는 점과, 유효기간이 90일에 불과하다는 점이다. == SNI (Server Name Indication) == SNI(Server Name Indication)은 TLS 핸드세이킹 과정에서 접속하고자 하는 호스트네임(예: librewiki.net)을 제시하여 서버가 알맞은 인증서를 제시하도록 하는 프로토콜 확장이다. TLS 핸드세이킹 과정에서 서버가 인증서를 제시하면 클라이언트는 이 인증서가 올바른 인증서인지 검사한다. 이떄 하나의 IP주소에서 여러개의 사이트를 호스팅하는 경우, (SNI 확장이 없다면) 서버 관리자는 인증서에 호스팅하는 모든 도메인을 포함하여야 한다.<ref>Host 헤더가 보내지기 전(HTTP 헤더가 보내지기 전)에 TLS 핸드세이킹이 시작되기 때문이다.</ref> '''그러나 이는 매우 번거롭다.'''<ref>호스팅 하나 추가되면 재발급해야 하는 것은 상식적으로 생각해도 매우 번거로운 일이다.</ref> 따라서 TLS 핸드세이킹 과정에서 평문으로<ref>인증서도 아직 제시받지 못한 상태이므로 암호화가 어려우나 이또한 암호화하기 위한 초안이 작성되고 있다.</ref> 접속하고자 하는 호스트네임을 같이 보내주게 하여 호스트네임별로 알맞은 인증서를 서버가 제시할 수 있도록 하는 SNI 확장이 개발되었으며, 현재 대다수의 주요 브라우저들은 이를 지원하고 있다. 현재 문화체육관광부에서 SNI확장에서 호스트네임이 암호화되지 않는 점을 노려, 이를 이용해 Https 사이트 접속을 차단하고자 하는 노력을 하고 있다.--어려분의 세금이 이런 곳에 쓰이고 있습니다!-- {{각주}}'