<div id="readability-page-1" class="page"><div><p><span>
      <span></span>
  <img alt="https" title="https" src="https://kyun2da.dev/static/dcdb73f0c00439b83f756d7423df917d/5a190/https.png" sizes="(max-width: 800px) 100vw, 800px" loading="lazy">
    </span></p>
<h2 id="https의-정의와-등장-배경"><a href="#https%EC%9D%98-%EC%A0%95%EC%9D%98%EC%99%80-%EB%93%B1%EC%9E%A5-%EB%B0%B0%EA%B2%BD" aria-label="https의 정의와 등장 배경 permalink"></a>HTTPS의 정의와 등장 배경</h2>
<p>HTTPS란 (HyperText Transfer Protocol over Secure Socket Layer)의 약자로, HTTP위에 SSL의 보안 프로토콜이 추가된 형태를 말한다.</p>
<p>이는 아래와 같은 <code>HTTP의 보안상 약점을 개선하기 위해</code> 넷스케이프 커뮤니케이션즈 코퍼레이션이 개발하였다.</p>
<ul>
<li>평문(암호화 하지 않은) 통신이기 때문에 패킷을 수집하여 <strong>도청 가능</strong>하다.</li>
<li>통신 상대를 확인하지 않기 때문에 <strong>위장 가능</strong>하다.</li>
<li>완전성(정보의 정확성) 즉, 발신된 리퀘스트나 리스폰스와 수신한 리퀘스트나 리스폰스가 같은지를 증명할 수 없기 때문에 <strong>변조 가능</strong>하다.</li>
</ul>
<p>그렇다면 이를 해결한 HTTPS는 어떠한 특징을 가지고 있는지 살펴보자.</p>
<h2 id="https의-특징"><a href="#https%EC%9D%98-%ED%8A%B9%EC%A7%95" aria-label="https의 특징 permalink"></a>HTTPS의 특징</h2>
<p>앞서 말했듯이 HTTPS는 HTTP에 <code>SSL</code>이나 <code>TLS</code>가 추가된 형식이다.</p>
<p>보통 HTTP는 직접 TCP와 통신하지만 HTTPS는 SSL과 통신하고 SSL이 TCP와 통신하게 된다. SSL은 공개키 암호의 방식을 사용하는데, 이 방식은 수신한 공개키가 본래 의도한 서버가 발행한 공개키인지를 증명할 수가 없어서 인증 기관을 두어 그 약점을 보완하였다. 인증기관은 다음과 같은 순서로 이용된다.</p>
<ol>
<li>서버의 운영자가 인증 기관에 서버의 공개키를 등록한다.</li>
<li>인증기관은 인증 기관의 비밀키로 서버의 공개키에 디지털 서명을하여 서명이 끝난 공개키를 만든다.</li>
<li>서버는 이 인증 기관에 의해서 작성된 공개키 인증서를 클라이언트에 보내고 공개키 암호로 통신을 한다.</li>
<li>증명서를 받은 클라이언트는 증명 기관의 공개키를 사용해서 서버의 공개키를 인증한 것이 진짜 인증 기관이라는 것과 서버의 공개키가 신뢰할 수 있다는 것을 알 수 있다.</li>
</ol>
<p>위와 같은 인증기관 추가와 SSL의 사용으로 HTTP의 단점을 해결하여 다음과 같은 장점을 가질 수 있었다.</p>
<ul>
<li><code>통신 암호화</code>(SSL이나 TLS라는 다른 프로토콜을 조합하여 HTTP의 통신 내용을 암호화)</li>
<li><code>상대를 확인</code>하는 증명서(제3자 기관에 의해 발행되는 증명서를 통해 클라이언트가 내가 통신하고자 하는 상대인지 아닌지 판단)</li>
</ul>
<p>이제, HTTPS를 사용하여 클라이언트와 서버가 어떻게 통신을 진행하는지 알아보도록 하자.</p>
<h2 id="https-통신-흐름"><a href="#https-%ED%86%B5%EC%8B%A0-%ED%9D%90%EB%A6%84" aria-label="https 통신 흐름 permalink"></a>HTTPS 통신 흐름</h2>
<ol>
<li>클라이언트가 <strong>Client Hello</strong> 메시지를 보내면서 SSL 통신을 시작한다. 메시지에는 클라이언트가 제공하는 SSL 버전을 지정하고, 암호 스위트로 불리는 리스트등이 포함되어 있다.</li>
<li>서버가 SSL 통신이 가능한 경우에는 <strong>Server Hello</strong> 메시지로 응답하고 클라이언트와 같이 SSL 버전과 암호 스위트를 포함한다.</li>
<li>서버가 <strong>Certificate</strong> 메시지를 보낸다. 메시지에는 공개키 증명서가 포함되어 있다.</li>
<li>서버가 <strong>Server Hello Done</strong> 메시지를 보내고 최초의 SSL negotiation이 끝났음을 알린다.</li>
<li>클라이언트가 <strong>Client Key Exchange</strong> 메시지로 응답한다. 메시지에는 통신을 암호화 하는데 사용하는 Pre-Master secret이 포함되어 있다.</li>
<li>클라이언트는 <strong>Change Cipher Spec</strong> 메시지를 보낸다. 이 메시지는 이 메시지 이후의 통신은 암호키를 사용해서 진행한다는 것을 나타내고 있다.</li>
<li>클라이언트는 <strong>Finished</strong> 메시지를 보낸다. 이 메시지는 접속 전체의 체크값을 포함하며, 네고시에이션이 성공했는지는 서버가 이 메시지를 올바르게 복호화할 수 있느냐에 따라 결정된다.</li>
<li>서버에서도 마찬가지로 <strong>Change Cipher Spec</strong> 메시지를 보낸다.</li>
<li>서버에서 마찬가지로 <strong>Finished</strong> 메시지를 보낸다.</li>
<li>서버와 클라이언트의 Finished 메시지 교환이 완료되면 SSL에 의한 접속이 확립되고 통신은 SSL에 의해 보호된 상태로 애플리 케이션 계층의 프로토콜에 의해 통신을 하게된다. 즉, <strong>HTTP 리퀘스트</strong>를 보낸다.</li>
<li>서버가 <strong>HTTP 리스폰스</strong>를 보낸다.</li>
<li>클라이언트가 접속을 끊고, <strong>close_notify</strong> 메시지를 송신한다. 이후 <strong>FIN</strong> 메시지를 보내 TCP 통신을 종료한다.</li>
</ol>
<p>위의 과정을 그림으로 나타내면 다음과 같다.</p>
<p><span>
      <span></span>
  <img alt="https 과정" title="https 과정" src="https://kyun2da.dev/static/c146b5a07e442c48d900034b2610ae3e/37523/https_process.png" sizes="(max-width: 720px) 100vw, 720px" loading="lazy">
    </span></p>
<p>위 과정에 더하여 애플리케이션 계층의 데이터를 송신할 때 MAC(Message Authentication Code)라고 부르는 메시지 다이제스트를 덧붙일 수 도 있다. 이를 이용하면 변조를 감지할 수 있어서 완전성 보호를 실현할 수 있다.</p>
<h2 id="https는-보안상의-이점밖에-없는가"><a href="#https%EB%8A%94-%EB%B3%B4%EC%95%88%EC%83%81%EC%9D%98-%EC%9D%B4%EC%A0%90%EB%B0%96%EC%97%90-%EC%97%86%EB%8A%94%EA%B0%80" aria-label="https는 보안상의 이점밖에 없는가 permalink"></a>HTTPS는 보안상의 이점밖에 없는가?</h2>
<p>HTTPS로 전환하게 되면 <code>검색엔진 최적화(SEO)에 있어서도 큰 혜택</code>을 볼 수 있다. 구글이 HTTPS 웹사이트에 가산점을 주는 이유 때문이기도 하지만, 사용자들이 결국에는 가장 안전하다고 생각하는 사이트를 더 많이 방문하기 때문이다. 또한 <code>가속화된 모바일 페이지(AMP, Accelerated Mobile Pages)</code>를 만들고 싶을 때도 HTTPS 프로토콜을 사용해야 한다.</p>
<h2 id="모든-사이트는-https를-사용하는게-좋을까"><a href="#%EB%AA%A8%EB%93%A0-%EC%82%AC%EC%9D%B4%ED%8A%B8%EB%8A%94-https%EB%A5%BC-%EC%82%AC%EC%9A%A9%ED%95%98%EB%8A%94%EA%B2%8C-%EC%A2%8B%EC%9D%84%EA%B9%8C" aria-label="모든 사이트는 https를 사용하는게 좋을까 permalink"></a>모든 사이트는 HTTPS를 사용하는게 좋을까?</h2>
<p>HTTPS 가 HTTP보다 보안과 SEO측면에서 좋다고 볼 수 있지만 HTTPS는 평문 통신인 HTTP에 비해 <code>CPU나 메모리 리소스가 많이 필요</code>하다. 따라서 엑세스가 많은 웹 사이트 등에서 암호화를 하면 부하가 상당하다. 또한 Let’s Encrypt와 같은 무료 증명서를 이용하지 않는경우라면 <code>증명서를 구입하는 비용</code>도 생각해 봐야할 문제이기도 하다.</p>
<h2 id="번외--ssl과-tls-차이"><a href="#%EB%B2%88%EC%99%B8--ssl%EA%B3%BC-tls-%EC%B0%A8%EC%9D%B4" aria-label="번외  ssl과 tls 차이 permalink"></a>번외 : SSL과 TLS 차이</h2>
<blockquote>
<p>SSL 규약은 처음에 넷스케이프가 만들었다. 1.0 버전은 공개 된 적이 없고, 2.0 버전이 1995년 2월에 이르러서야 릴리스가 된다. 그러나 이 버전은 많은 보안 결함 때문에 3.0 버전으로 곧바로 이어진다. 3.0은 1996년 릴리스 된다. 결국 3.0 버전은 TLS 버전 1.0의 기초가 되고, IETF에서 1999년 1월에 RFC 2246 표준 규약으로 정의하게 된다. 마지막 갱신은 RFC 5246 이었다.</p>
</blockquote>
<p>위의 내용은 나무위키에서 TLS의 역사를 가져왔다. 한마디로 SSL을 개선한 것이 TLS라고 보면 좋다.</p>
<h2 id="참고"><a href="#%EC%B0%B8%EA%B3%A0" aria-label="참고 permalink"></a>참고</h2>
<ul>
<li><a href="https://ko.wikipedia.org/wiki/HTTPS">HTTPS - 위키백과</a></li>
<li><a href="http://blog.wishket.com/http-vs-https-%EC%B0%A8%EC%9D%B4-%EC%95%8C%EB%A9%B4-%EC%82%AC%EC%9D%B4%ED%8A%B8%EC%9D%98-%EB%A0%88%EB%B2%A8%EC%9D%B4-%EB%B3%B4%EC%9D%B8%EB%8B%A4/">HTTP vs HTTPS 차이 - 위시캣 블로그</a></li>
<li><a href="https://engineering.linecorp.com/ko/blog/best-practices-to-secure-your-ssl-tls/">안전한 SSL/TLS를 운영하기 위해 알아야 하는 것들</a></li>
</ul></div></div>

Kyun2da.dev

Kyun Heo

HTTPS의 정의와 등장 배경
HTTPS란 (HyperText Transfer Protocol over Secure Socket Layer)의 약자로, HTTP위에 SSL의 보안 프로토콜이 추가된 형태를 말한다.
이는 아래와 같은 HTTP의 보안상 약점을 개선하기 위해 넷스케이프 커뮤니케이션즈 코퍼레이션이 개발하였다.
평문(암호화 하지 않은) 통신이기 때문에 패킷을 수집하여 도청 가능하다.
통신 상대를 확인하지 않기 때문에 위장 가능하다.
완전성(정보의 정확성) 즉, 발신된 리퀘스트나 리스폰스와 수신한 리퀘스트나 리스폰스가 같은지를 증명할 수 없기 때문에 변조 가능하다.
그렇다면 이를 해결한 HTTPS는 어떠한 특징을 가지고 있는지 살펴보자.
HTTPS의 특징
앞서 말했듯이 HTTPS는 HTTP에 SSL이나 TLS가 추가된 형식이다.
보통 HTTP는 직접 TCP와 통신하지만 HTTPS는 SSL과 통신하고 SSL이 TCP와 통신하게 된다. SSL은 공개키 암호의 방식을 사용하는데, 이 방식은 수신한 공개키가 본래 의도한 서버가 발행한 공개키인지를 증명할 수가 없어서 인증 기관을 두어 그 약점을 보완하였다. 인증기관은 다음과 같은 순서로 이용된다.
서버의 운영자가 인증 기관에 서버의 공개키를 등록한다.
인증기관은 인증 기관의 비밀키로 서버의 공개키에 디지털 서명을하여 서명이 끝난 공개키를 만든다.
서버는 이 인증 기관에 의해서 작성된 공개키 인증서를 클라이언트에 보내고 공개키 암호로 통신을 한다.
증명서를 받은 클라이언트는 증명 기관의 공개키를 사용해서 서버의 공개키를 인증한 것이 진짜 인증 기관이라는 것과 서버의 공개키가 신뢰할 수 있다는 것을 알 수 있다.
위와 같은 인증기관 추가와 SSL의 사용으로 HTTP의 단점을 해결하여 다음과 같은 장점을 가질 수 있었다.
통신 암호화(SSL이나 TLS라는 다른 프로토콜을 조합하여 HTTP의 통신 내용을 암호화)
상대를 확인하는 증명서(제3자 기관에 의해 발행되는 증명서를 통해 클라이언트가 내가 통신하고자 하는 상대인지 아닌지 판단)
이제, HTTPS를 사용하여 클라이언트와 서버가 어떻게 통신을 진행하는지 알아보도록 하자.
HTTPS 통신 흐름
클라이언트가 Client Hello 메시지를 보내면서 SSL 통신을 시작한다. 메시지에는 클라이언트가 제공하는 SSL 버전을 지정하고, 암호 스위트로 불리는 리스트등이 포함되어 있다.
서버가 SSL 통신이 가능한 경우에는 Server Hello 메시지로 응답하고 클라이언트와 같이 SSL 버전과 암호 스위트를 포함한다.
서버가 Certificate 메시지를 보낸다. 메시지에는 공개키 증명서가 포함되어 있다.
서버가 Server Hello Done 메시지를 보내고 최초의 SSL negotiation이 끝났음을 알린다.
클라이언트가 Client Key Exchange 메시지로 응답한다. 메시지에는 통신을 암호화 하는데 사용하는 Pre-Master secret이 포함되어 있다.
클라이언트는 Change Cipher Spec 메시지를 보낸다. 이 메시지는 이 메시지 이후의 통신은 암호키를 사용해서 진행한다는 것을 나타내고 있다.
클라이언트는 Finished 메시지를 보낸다. 이 메시지는 접속 전체의 체크값을 포함하며, 네고시에이션이 성공했는지는 서버가 이 메시지를 올바르게 복호화할 수 있느냐에 따라 결정된다.
서버에서도 마찬가지로 Change Cipher Spec 메시지를 보낸다.
서버에서 마찬가지로 Finished 메시지를 보낸다.
서버와 클라이언트의 Finished 메시지 교환이 완료되면 SSL에 의한 접속이 확립되고 통신은 SSL에 의해 보호된 상태로 애플리 케이션 계층의 프로토콜에 의해 통신을 하게된다. 즉, HTTP 리퀘스트를 보낸다.
서버가 HTTP 리스폰스를 보낸다.
클라이언트가 접속을 끊고, close_notify 메시지를 송신한다. 이후 FIN 메시지를 보내 TCP 통신을 종료한다.
위의 과정을 그림으로 나타내면 다음과 같다.
      
  
    
위 과정에 더하여 애플리케이션 계층의 데이터를 송신할 때 MAC(Message Authentication Code)라고 부르는 메시지 다이제스트를 덧붙일 수 도 있다. 이를 이용하면 변조를 감지할 수 있어서 완전성 보호를 실현할 수 있다.
HTTPS는 보안상의 이점밖에 없는가?
HTTPS로 전환하게 되면 검색엔진 최적화(SEO)에 있어서도 큰 혜택을 볼 수 있다. 구글이 HTTPS 웹사이트에 가산점을 주는 이유 때문이기도 하지만, 사용자들이 결국에는 가장 안전하다고 생각하는 사이트를 더 많이 방문하기 때문이다. 또한 가속화된 모바일 페이지(AMP, Accelerated Mobile Pages)를 만들고 싶을 때도 HTTPS 프로토콜을 사용해야 한다.
모든 사이트는 HTTPS를 사용하는게 좋을까?
HTTPS 가 HTTP보다 보안과 SEO측면에서 좋다고 볼 수 있지만 HTTPS는 평문 통신인 HTTP에 비해 CPU나 메모리 리소스가 많이 필요하다. 따라서 엑세스가 많은 웹 사이트 등에서 암호화를 하면 부하가 상당하다. 또한 Let’s Encrypt와 같은 무료 증명서를 이용하지 않는경우라면 증명서를 구입하는 비용도 생각해 봐야할 문제이기도 하다.
번외 : SSL과 TLS 차이
SSL 규약은 처음에 넷스케이프가 만들었다. 1.0 버전은 공개 된 적이 없고, 2.0 버전이 1995년 2월에 이르러서야 릴리스가 된다. 그러나 이 버전은 많은 보안 결함 때문에 3.0 버전으로 곧바로 이어진다. 3.0은 1996년 릴리스 된다. 결국 3.0 버전은 TLS 버전 1.0의 기초가 되고, IETF에서 1999년 1월에 RFC 2246 표준 규약으로 정의하게 된다. 마지막 갱신은 RFC 5246 이었다.
위의 내용은 나무위키에서 TLS의 역사를 가져왔다. 한마디로 SSL을 개선한 것이 TLS라고 보면 좋다.
참고
HTTPS - 위키백과
HTTP vs HTTPS 차이 - 위시캣 블로그
안전한 SSL/TLS를 운영하기 위해 알아야 하는 것들

https에 대해서

댓글