위키원
"HTTPS"의 두 판 사이의 차이
잔글 |
잔글 (오타 수정 HPPT -> HTTP) |
||
| (사용자 5명의 중간 판 23개는 보이지 않습니다) | |||
| 1번째 줄: | 1번째 줄: | ||
| − | '''HTTPS'''는 [[HTTP]] 통신을 | + | '''HTTPS'''(에이치티티피에스)는 [[HTTP]] 통신을 [[암호화]]하여 만든 [[프로토콜]]이다. HTTPS는 "HyperText Transfer Protocol over SSL"의 약자로서, "http secure" 또는 "http over SSL"이라고도 한다. 여기서 [[SSL]]은 "Secure Socket Layer"의 약자이다. '''에이치티티피에스'''라고 읽는다. 포트 번호는 443번이다. 보통 "https://"와 같이 소문자로 쓴다. |
== 개요 == | == 개요 == | ||
| − | HTTPS는 [[ | + | HTTPS는 기존 [[HTTP]]에 비해 [[보안성]]을 강화한 [[프로토콜]]이다. HTTPS는 통신의 인증과 암호화를 위해 넷스케이프 커뮤니케이션즈(Netscape Communications)는 1994년에 넷스케이프 네비게이터 웹브라우저를 위해 HTTPS를 개발하였다. 원래 HTTPS는 SSL 프로토콜과 함께 사용되었다. SSL이 TLS으로 발전한 시기인 2000년 5월, HTTPS는 공식적으로 RFC 2818에 규정되었다. [[전자상거래]]와 클라이언트-서버 간 의 정보교환 시에 자주 쓰이며 암호화 프로토콜인 [[SSL]] 이나 [[TLS]] 프로토콜을 사용하여 통신을 주고받는다. 일반적으로 HTTP 프로토콜의 문제점은 서버에서부터 브라우저로 전송되는 정보가 암호화되지 않고 전송이 된다는 것이었다. 즉, 데이터가 쉽게 도난당할 수 있다는 것이었는데, 이를 극복하기 위해 HTTPS 프로토콜에 SSL을 사용함으로써 등장하게 되었다. 인터넷 통신이 발달함에 따라 네트워크상에서 발생하는 전자상거래, 은행 기관인증, 개인정보를 담고 있는 데이터는 타인이 쉽게 접근할 경우에는 해킹의 문제가 발생하기 때문에 암호화 프로토콜을 이용하여 통신 프로토콜을 사용하게 되었다. 한편, 네이버나 구글에 접속하여 URL을 보면 왼쪽에 자물쇠 모양이 있는데 이는 HTTPS로 암호화 된 상태를 의미한다. |
| − | |||
| − | + | 현재 HTTP/1.1을 대부분 사용 중이지만 구글 계열의 사이트는 HTTP/2와 HTTP/1.1을 동시에 지원하며 점진적으로 HTTP/2로 바뀌는 추세이다. HTTP/2는 HTTPS 연결에서만 작동하며, HTTP 연결일 경우에는 브라우저와 서버에서 HTTP/2를 지원하더라도 HTTP/1.1로 연결된다. HTTP/2는 [[구글]]이 발표한 비표준 개방형 네트워크 프로토콜인 SPDY 기술을 기반으로 했는데, HTTP/3에도 구글이 발표한 QUIC(Quick UDP Internet Connections) 프로토콜 기술이 적용된다. HTTP/2까지는 TCP 연결을 기반으로 하는데, HTTP over QUIC(HTTP/3)은 UDP 연결을 기반으로 한다.<ref>HTTP 나무위키 - https://namu.wiki/w/HTTP</ref> 인터넷에서 일어나는 금융거래 및 전자상거래, 데이터 정보의 통신프로토콜의 발달로 개인의 프라이버시가 중요해짐에 따라서, 구글 크롬과 같은 웹브라우저들은 HTTP 웹사이트를 위험성이 있다고 경고문을 표시하고 있다. 국내기업 중 네이버㈜와 다음이 TTPS를 점차 확대하고있다. | |
| − | |||
| − | |||
| − | |||
==역사== | ==역사== | ||
| − | 1996년 첫 상용화 버전인 HTTP/1.0 발표 | + | * '''1996년''' : 첫 상용화 버전인 HTTP/1.0 발표 |
| + | * '''1999년''' : HTTP/1.1 발표 | ||
| + | * '''2015년''' : HTTP/2 공식발표 | ||
| − | + | == 특징 == | |
| + | === 동작원리 === | ||
| + | 응용계층에서 동작하는 HTTP는 TCP/IP(4계층)과 통신을 주고받기위해 소켓을 이용하게 된다. 사실 TCP 계층과 응용계층 사이에는 어떠한 계층이 존재하지 않는데, HTTPS 프로토콜은 이 두 개의 계층 사이에 SSL 계층이 포함되어 있다. 즉, HTTPS는 SSL 위에서 프로토콜이 실행된다. SSL은 일종의 독립적인 보안 계층으로 프로토콜을 실행하는데, 그 이유는 서로 다른 계층 간의 통신에서 소켓이 SSL과 연결되어 SSL이 보안 프로토콜 기능을 제안하기 때문이다.<ref>victolee, 〈[https://victorydntmd.tistory.com/95 (HTTPS)HTTPS와 SSL인증서]〉, 《티스토리》, 2017-12-10</ref> 즉 SSL 프로토콜을 적용하면 SSL을 TCP로 인식하고 TCP는 정상적으로 통신이되어져 HPPTS 프로토콜을 실행하는데 아무 문제가 없다. HTTPS는 HTTP 헤더와 요청·응답 데이터를 비롯한 모든 메시지 내용을 암호화한다. | ||
| − | + | * '''[[SSL]]''' : 전송 계층을 보안하는 프로토콜로 컴퓨터 네트워크에 통신 보안을 제공하기 위해 설계된 암호 규약이다. TLS(Transport Layer Securtiy)라고도 부르며 이는 SSL이 표준화가 됨에 따라 이름이 변경되었다. 이 규약은 인터넷같이 TCP/IP 네트워크를 사용하는 통신에 적용되며, 통신 과정에서 전송계층 종단 간 보안과 데이터 무결성을 확보해준다. 이 규약은 웹 브라우징, 전자 메일, 인스턴트 메신저, VoIP 같은 응용 부분에 적용되고 있다. 처음 만들어진 1.0버전이 보안 문제로 취약하여 보안 문제를 극복하기 위해 새로운 버전을 출시했으며 결국 3.0 버전이 국제 인터넷 표준화 기구(IETF)에 의해 현재 구식(deprecate)으로 간주하여 TLS 1.0을 만드는데 참조가 되었다. 최종 갱신은 RFC 5246이고, 최종 갱신 버전은 넷스케이프에서 만든 SSL 표준을 바탕으로 했다.<ref> 전송 계층 보안 위키백과 - https://ko.wikipedia.org/wiki/%EC%A0%84%EC%86%A1_%EA%B3%84%EC%B8%B5_%EB%B3%B4%EC%95%88</ref> 보안성을 가진 프로토콜로 인증기관을 통해 가고자 하는 서버의 인증서를 받게 되면 클라이언트의 정보를 암호화하여 전달하는 역활을 한다. | |
| − | 현재 | ||
| − | + | === 서버설정 및 암호화=== | |
| − | + | HTTPS 연결을 허용하기에 클라이언트는 본인이 접속하는 서버가 신뢰할만한 서버인지 확인을 해야 하는 데 이 신원을 보증하기 위해서는 제3자의 입장인 인증기관(Certificate Authority)을 필요로 한다. HTTPS를 연결하기에 서버의 관리자는 [[공개키]]와 [[개인키]]를 만들고 신뢰할만한 인증 기간에 비용을 지불하고 공개키를 맡긴다. 인증기관은 암호화된 서버의 공개키를 다른 클라이언트와 서버에게 제공 하고 암호화된 공개키를 받은 서버는 해당 클라이언트에 이를 전달한다. 클라이언트는 인증기관을 통해 인증서 리스트를 탐색하게 되고 인증기관의 이름이 같게 되면 해당 인증기관은 공개키를 얻게 된다. 얻은 데이터를 본인만의 개인 키로 복호화한 후 정보를 받게된다.<ref>정아마추어 JEONG_AMATEUR, 〈[https://jeong-pro.tistory.com/89 Http와 Https 이해와 차이점 그리고 오해(?)]〉, 《티스토리》, 2017-11-5</ref> HTTPS HTTPS 암호화 기술의 주요 특징은 다음과 같다. | |
| − | + | [[파일:공개키암호화.png|400픽셀|섬네일|오른쪽|공개키 암호화 과정]] | |
| − | + | * '''기밀성''' : 프라이버시로서, 인증되지 않은 제3자가 정보를 읽지 못하도록 정보를 보호하는 역할을 한다. 그 과정에서 듣거나 볼 수 있는, 보통 평문이라고 하는 읽을 수 있는 정보 형식을 암호문이라고 하는 뒤죽박죽 읽을 수 없는 데이터 형식으로 변환하는 작업을 거친다. 이 과정을 암호화라고 한다. 암호문을 다시 읽을 수 있는 평문으로 전환하는 반대의 과정을 복호화라고 한다. 정보를 암호화하고 복호화하는 방법에는 서버와 클라이언트 간에 공통된 공개키를 가지는 대칭키 암호화 방식, 인코딩과 디코딩이 다른(암호화하고 복호화하는데 사용되는 키가 다름을 의미) 공개키 암호화 방식 등이 존재한다.<ref NAME= "SM">Vladislav Denishev, 〈[https://webactually.com/2018/11/http%EC%97%90%EC%84%9C-https%EB%A1%9C-%EC%A0%84%ED%99%98%ED%95%98%EA%B8%B0-%EC%9C%84%ED%95%9C-%EC%99%84%EB%B2%BD-%EA%B0%80%EC%9D%B4%EB%93%9C/ HTTP에서 HTTPS로 전환하기 위한 완벽 가이드]〉, 《웹엑추얼리》, 2018-11-13</ref> 그렇기 때문에 암호화를 하여 사용자의 정보를 보호한다. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | * '''무결성''' : HTTPS로 해결하는 또 다른 문제는 데이터 무결성이다. 즉, 전체 정보가 목적지에 도착했으며, 전송 중에 외부의 공격으로 변조되지 않았음을 보장한다. 정보가 잘 전송되었음을 보장하기 위해 메시지 다이제스트 알고리즘을 사용한다. 교환된 각 메시지의 메시지 인증 코드(message authentication codes, MAC)계산은 암호화 해싱 프로세스다. 즉 데이터가 잘 도착했는지 여부를 암호화된 메시지를 주고받음으로 확인한다.<ref NAME= "SM"></ref> | |
| − | |||
| − | |||
| − | + | * '''대칭키''' : 서버와 클라이언트가 같은 키로 데이터를 통신한다. 흔히 암호화 알고리즘이라 부르는데, 암복호화 시 간편하고 드는 비용이 적다. 송수신자 양단은 하나의 키를 사용하여야 하며 이 대칭키는 하나의 키로 암호가 되어있기 때문에 보안상 유출이 된다면 암호의 내용이 해커에 의해 복호화된다는 치명적인 단점을 가지고 있다. 이를 보안을 유지하기 위해 나온 방법이 비대칭키 암호화 방식이다. | |
| − | |||
| − | |||
| − | |||
| − | + | * '''비대칭 키''' : 공개키, 비공개키 방식을 가지고 데이터를 암복호화한다. 공개키로 암호화를 한다면 비공개키로 복호화를 해야 하고 마찬가지로 비공개키로 암호화를 한다면 공개키로 복호화를 해야 한다. 이 방식을 사용하여 두 개의 키 중 하나는 비공개키 혹은 개인키, 보안키(secure key)라고 하며 나머지를 공개키라고 부른다. 비공개키는 사용자 호스트만이 알고 읽을 수 있고 공개키는 다른 사용자에게 제공한다. 이러한 방식을 사용하여 공인 인증기관를 이용하여 인증서를 주고받아 원활한 HTTPS 동작을 수행한다. | |
| − | ''' | ||
| − | + | === 인증서 === | |
| − | + | 클라이언트가 서버에 접속하기 위해서는 먼저는 본인이 접속하려는 서버가 인증이 보장되는지 판단을 내려야 하는데 이때 [[인증서]]에 등록된 정보를 가지고 인증기관에 공개키를 요청하게 된다. 이를 인증서를 통한 인증과정이라 한다. HTTPS는 보안 프로토콜로서 서버의 접속자와 서버 간의 주고받는 데이터의 암호화가 필수인데 이를 지정하고 인증서를 보관하는 인증기관은 신뢰성이 매우 우수해야 하며 정확한 절차로 인증이 된 공인 기업들만이 참여한다. 만약 웹 개발자가 서버를 만들 게되면 공개키를 믿을 수 있는 인증기관에 맡기게 된다. 인증기관은 공개키를 가지고 인증서를 만들고 이를 암호화하여 서버에게 전달한다. 인증서의 절차는 아래와 같은 방식으로 진행된다. | |
| − | + | ||
| − | + | # 클라이언트는 서버로부터 받은 인증서가 인증기관에 의해 발급이 된 여부를 먼저 파악하기 위해 클라이언트 내에 저장된 인증기관 리스트를 컨펌한다. | |
| − | + | # 컨펌이 된다면 해당 인증기관의 공개키로 인증서를 복호화 하고 이는 비공개키로 암호화됨을 의미한다. | |
| + | # 이러한 방식으로 인증서를 전송한 서버를 신뢰하게 된다. | ||
| + | |||
| + | 한마디로 말하면, 인증서의 역할은 클라이언트가 접속한 서버가 신뢰 할 수 있는 서버임을 보장하고 | ||
| + | SSL 통신에 사용할 공개키를 클라이언트에게 제공하는 것이다.<ref>코딩초보 여성계, 〈[https://coding-start.tistory.com/208 네트워크 - HTTP/HTTPS 차이점, HTTPS란?]〉《티스토리》, 2019-08-01</ref> 인증서를 발급한 기관명, 서비스 및 도메인 정보, 서버 측 공개키, 공개키의 암호화 방법 SSL 인증서 안에 기록되어 있다. | ||
| + | |||
| + | == 통신방법 == | ||
| + | [[파일:쓰리핸드쉐이크.png|400픽셀|섬네일|오른쪽|설명]] | ||
| − | + | 컴퓨터와 컴퓨터간에 통신 방법에는 쓰리 핸드쉐이크(3-Handshake) 방식이 사용되며 핸드쉐이크 => 세션 => 세션종료로 진행한다. 핸드쉐이크는 악수라는 뜻인데, 사람사이에서도 먼저 악수를 하며 인사한다. 이를 통해 상대방의 분위기나 기분을 파악 할 수 있고 서로 원활한 커뮤니케이션을 할 수 있다. | |
| − | |||
| − | + | * '''핸드쉐이크''' 클라이언트와 서버는 서로 정보를 주고받기 전에 SSL 인증서를 먼저 주고받는다. 서로 간에 암호화 방식이 다를 수 있음으로 협상, 즉 동기화를(synchronization) 맺는 단계이다. 클라이언트가 암호화 방식을 서버에 발신하면 서버는 이를 받고 본인도 사용할 수 있는 암호화 방식을 택하여 다시 클라이언트에게 ACK(응답)와 SNY(동기화)를 보낸다. 이는 동기화를 하기 위한 과정이라고 할 수 있다. 클라이언트는 서버로부터 응답을 받게 되고 협상을 마치게 된다. | |
| − | ''' | + | * '''세션''' : 실제 데이터가 오가는 동작 상태를 말한다. 앞서 암호화 방식에 대한 동기화를 했기 때문에 대칭키,비대칭키 방식으로 암호화된 정보를 주고받는다. |
| − | + | * '''세션종료''' : 주고받을 데이터가 없을 때에 세션을 종료하게 된다. | |
| − | + | === 비교 === | |
| − | + | HTTPS URL은 기본적으로 "https : //"로 시작하고 포트 443을 사용하지만 [[HTTP]] URL은 기본적으로 "http : //"로 시작하고 포트 80을 사용한다. SSL 인증서를 통해 사용자가 사이트에 제공하는 정보를 암호화하는데, 쉽게 말하면 데이터를 암호로 바꾸는 의미이다. 이렇게 전송된 데이터는 중간에서 누군가 훔쳐낸다고 하더라도 데이터가 암호화되어있기 때문에 해독할 수 없다. 한가지 예를 들면 512 비트(평균적으로 128비트 암호화)의 암호화라면, 2의 256승을 대입해야하며, 이것은 1,237,940,039,285 ....000(중략)이라는 기하급수적인 수를 대입해야 한다는 뜻과 같다. 그렇기 때문에 현재까지 나온 컴퓨터라 해도 적게는 몇백 년, 많게는 몇천 년 까지 계산을 해야 되는 문제가 발생한다. 그 외에도 HTTPS는 TLS 프로토콜을 통해서도 보안을 유지하고 TLS는 [[데이터]] [[무결성]]을 제공하기 때문에 데이터가 전송 중에 수정되거나 손상되는 것을 방지하며, 사용자가 자신이 의도하는 웹사이트와 통신하고 있음을 입증하는 인증 기능도 제공한다. 서버-클라이언트 간의 데이터 송수신 시 암호화와 복호화 과정을 통해 데이터를 주고받기 때문에 HTTP보다 신뢰성이 뛰어나긴 하지만 여기서 발생하게 되는 데이터의 자원 소모가 발생하여 통신속도가 HTTP보다 느리다. 흔히 보안성이 낮아도 되는 온라인 뉴스나 기사에 HTTP를 사용하고 금융과 관련된 보안업무나 개인의 데이터 보호에 많이 사용된다. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | SSL 인증서 | + | === 문제점 === |
| − | + | HTTPS의 문제점은 사용 시 반드시 증명서를 구입해야 한다는 것이다. 증명서의 구입 비용이 부담되는 서비스나 개인 웹사이트의 경우 [[HTTP]]만 선택하기도 한다. 그리고 HTTPS를 사용할 경우 처리가 늦어지게 되는 단점이 있다. 그 이유는 클라이언트 요청 시, SSL에 필요한 통신이 추가되고, 암호화 복호화 계산을 하므로 서버나 클라이언트의 리소스를 추가적으로 소비하기 때문이다.<ref>손님1, 〈[https://blog.sonim1.com/99 10. HTTPS란?]〉, 《KENDRIC's BLOG》, 2016-04-12</ref> 인증기관은 매우 엄격하고 공인으로 인증된 기업이여햐만 한다. 신뢰성이 없는 인증기관이라면 인터넷 접속 시 SSL 인증서 발급은 물론 사용자와 서버가 서로 주고받는 정보가 도청, 간섭, 방해를 받아 데이터를 손실 할 수 있기 때문이다. | |
| − | + | 사이버보안 업체인 [[파이어아이]](FireEye)는 최근 2019년 HTTPS를 이용한 피싱 이메일 공격이 17%증가 하였고, URL 기반 공격이 26%상승 했다고 이메일 위협 보고서를 발표했다. 일반적으로 피싱 이메일은 자격 증명 정보나 신용카드 정보를 탈취하기 위한 목적으로, 기존에 알고있는 연락처나 신뢰할 수 있는 회사를 사칭하여 이메일 수신인이 임베디드 링크를 클릭하도록 유도한다.<ref>길민권 기자, 〈[https://www.dailysecu.com/news/articleView.html?idxno=55046 2019년 1분기, HTTPS 이용 악성 URL 26% ↑, 피싱 시도 17% ↑]〉, 《데일리시큐》, 2019-07-16</ref> | |
| − | |||
| − | + | 이런 보안상의 문제를 해결하기 위해 정부는 HTTPS 사이트 접속 차단 조치를 내렸다. 이에대해 성균관대학교 지성우 법학 교수는 "온라인상의 불법 정보를 차단하는 일은 좋은 목적에서 시행한다 해도, 표현의 자유(인터넷의 속도성 자유성 개방성 제한)를 의식해야 한다" 고 말했다. 이런 논란으로 인해 반대하는 국민들과 정책을 시행하려는 정부 측의 의견이 엇갈리고 있다.<ref> 김평화 기자, 〈[https://news.mt.co.kr/mtview.php?no=2019060713237648466 'https' 사이트 접속차단 논란, "'불법'에 국민동의 필요"]〉, 《머니투데이》, 2019-06-07</ref> | |
| − | |||
| − | + | 물론 정부가 HTTPS 사이트 접속을 규제하긴 했다. 최근 기업의 서버/데이터 관리 또한 [[악성코드]]의 감염이 많이 일어나고 있고 구글은 HTTPS가 아니면 접근초차 못하게 한다. 하지만 현실은 불법 정보 사이트에 접속하면 http://warning.or.kr/ IP로 연결되어 경고문이 나오는 것을 심심치 않게 볼 수 있다. 이러한 정부의 적극적인 규제에 한때 [[DNS]]를 통한 사이트 우회, [[VPN]] 방식 등 여러 가지 어플들이 쏟아져 나왔고 해외와 달리 너무 엄격하다는 비난이 거센 적도 있었다. 그래도 과거보단 많은 불법 사이트가 규제되고 보안을 지키는 데 많은 도움이 되었다. 하지만 개인 SNS나 [[다크웹]] 을 보면 불법 정보, 동영상 등이 많이 있고 하나하나 IP를 추적해 규제를 가하는데는 어려움을 겪고 있다. IP주소는 굉장히 많기에 하나하나 규제를 가하는 것이 불가능해 보이긴 한다. 하지만 4차 산업혁명 시대에 더 많은 데이터와 통신을 요구하기에 앞으로 HTTPS의 암호화를 강화하고 적용하는 문제가 있다. | |
{{각주}} | {{각주}} | ||
== 참고자료 == | == 참고자료 == | ||
| − | *나무위키 | + | * HTTP 나무위키 - https://namu.wiki/w/HTTP |
| − | *victolee, 〈[https://victorydntmd.tistory.com/95/ | + | * victolee, 〈[https://victorydntmd.tistory.com/95/ (HTTPS)HTTPS와 SSL인증서]〉, 《티스토리》, 2017-12-11 |
| − | *정아마추어 JEONG_AMATEUR, 〈[https://jeong-pro.tistory.com/89 Http와 Https 이해와 차이점 그리고 오해(?)]〉,《티스토리》, 2017-11-5 | + | * 전송 계층 보안 위키백과 - https://ko.wikipedia.org/wiki/%EC%A0%84%EC%86%A1_%EA%B3%84%EC%B8%B5_%EB%B3%B4%EC%95%88 전송 계층 보안 |
| − | *Vladislav Denishev,〈[https://webactually.com/2018/11/http%EC%97%90%EC%84%9C-https%EB%A1%9C-%EC%A0%84%ED%99%98%ED%95%98%EA%B8%B0-%EC%9C%84%ED%95%9C-%EC%99%84%EB%B2%BD-%EA%B0%80%EC%9D%B4%EB%93%9C/ HTTP에서 HTTPS로 전환하기 위한 완벽 가이드]〉,《Smashing Magazine》, 2018-11-13 | + | * 정아마추어 JEONG_AMATEUR, 〈[https://jeong-pro.tistory.com/89 Http와 Https 이해와 차이점 그리고 오해(?)]〉, 《티스토리》, 2017-11-5 |
| − | *코딩초보 | + | * Vladislav Denishev, 〈[https://webactually.com/2018/11/http%EC%97%90%EC%84%9C-https%EB%A1%9C-%EC%A0%84%ED%99%98%ED%95%98%EA%B8%B0-%EC%9C%84%ED%95%9C-%EC%99%84%EB%B2%BD-%EA%B0%80%EC%9D%B4%EB%93%9C/ HTTP에서 HTTPS로 전환하기 위한 완벽 가이드]〉, 《Smashing Magazine》, 2018-11-13 |
| − | *손님1, 〈[https://blog.sonim1.com/99 10. HTTPS란?]〉, 《KENDRIC's BLOG》, 2016-04-12 | + | * 코딩초보 여성계, 〈[https://coding-start.tistory.com/208 네트워크 - HTTP/HTTPS 차이점, HTTPS란?]〉《티스토리》, 2019-08-01 |
| − | *길민권 기자, 〈[https://www.dailysecu.com/news/articleView.html?idxno=55046 2019년 1분기, HTTPS 이용 악성 URL 26% ↑, 피싱 시도 17% ↑]〉, 《데일리시큐》, 2019-07-16 | + | * 손님1, 〈[https://blog.sonim1.com/99 10. HTTPS란?]〉, 《KENDRIC's BLOG》, 2016-04-12 |
| + | * 길민권 기자, 〈[https://www.dailysecu.com/news/articleView.html?idxno=55046 2019년 1분기, HTTPS 이용 악성 URL 26% ↑, 피싱 시도 17% ↑]〉, 《데일리시큐》, 2019-07-16 | ||
* 김평화 기자, 〈[https://news.mt.co.kr/mtview.php?no=2019060713237648466 'https' 사이트 접속차단 논란, "'불법'에 국민동의 필요"]〉, 《머니투데이》, 2019-06-07 | * 김평화 기자, 〈[https://news.mt.co.kr/mtview.php?no=2019060713237648466 'https' 사이트 접속차단 논란, "'불법'에 국민동의 필요"]〉, 《머니투데이》, 2019-06-07 | ||
| + | * 카피켓, 〈[https://cryptocat.tistory.com/3 카피켓의 쉬운 암호학]〉, 《티스토리》, 2007-12-20 | ||
| + | * jm, 〈[https://m.blog.naver.com/uok02018496/221787888256 TCP-(3way handshaking & 4way handshaking)]〉, 《네이버 블로그》, 2020-1-28 | ||
== 같이 보기 == | == 같이 보기 == | ||
| 88번째 줄: | 80번째 줄: | ||
* [[웹]] | * [[웹]] | ||
* [[HTTP]] | * [[HTTP]] | ||
| + | * [[TCP/IP]] | ||
* [[프로토콜]] | * [[프로토콜]] | ||
{{인터넷|검토 필요}} | {{인터넷|검토 필요}} | ||
2022년 1월 15일 (토) 00:31 기준 최신판
HTTPS(에이치티티피에스)는 HTTP 통신을 암호화하여 만든 프로토콜이다. HTTPS는 "HyperText Transfer Protocol over SSL"의 약자로서, "http secure" 또는 "http over SSL"이라고도 한다. 여기서 SSL은 "Secure Socket Layer"의 약자이다. 에이치티티피에스라고 읽는다. 포트 번호는 443번이다. 보통 "https://"와 같이 소문자로 쓴다.
개요[편집]
HTTPS는 기존 HTTP에 비해 보안성을 강화한 프로토콜이다. HTTPS는 통신의 인증과 암호화를 위해 넷스케이프 커뮤니케이션즈(Netscape Communications)는 1994년에 넷스케이프 네비게이터 웹브라우저를 위해 HTTPS를 개발하였다. 원래 HTTPS는 SSL 프로토콜과 함께 사용되었다. SSL이 TLS으로 발전한 시기인 2000년 5월, HTTPS는 공식적으로 RFC 2818에 규정되었다. 전자상거래와 클라이언트-서버 간 의 정보교환 시에 자주 쓰이며 암호화 프로토콜인 SSL 이나 TLS 프로토콜을 사용하여 통신을 주고받는다. 일반적으로 HTTP 프로토콜의 문제점은 서버에서부터 브라우저로 전송되는 정보가 암호화되지 않고 전송이 된다는 것이었다. 즉, 데이터가 쉽게 도난당할 수 있다는 것이었는데, 이를 극복하기 위해 HTTPS 프로토콜에 SSL을 사용함으로써 등장하게 되었다. 인터넷 통신이 발달함에 따라 네트워크상에서 발생하는 전자상거래, 은행 기관인증, 개인정보를 담고 있는 데이터는 타인이 쉽게 접근할 경우에는 해킹의 문제가 발생하기 때문에 암호화 프로토콜을 이용하여 통신 프로토콜을 사용하게 되었다. 한편, 네이버나 구글에 접속하여 URL을 보면 왼쪽에 자물쇠 모양이 있는데 이는 HTTPS로 암호화 된 상태를 의미한다.
현재 HTTP/1.1을 대부분 사용 중이지만 구글 계열의 사이트는 HTTP/2와 HTTP/1.1을 동시에 지원하며 점진적으로 HTTP/2로 바뀌는 추세이다. HTTP/2는 HTTPS 연결에서만 작동하며, HTTP 연결일 경우에는 브라우저와 서버에서 HTTP/2를 지원하더라도 HTTP/1.1로 연결된다. HTTP/2는 구글이 발표한 비표준 개방형 네트워크 프로토콜인 SPDY 기술을 기반으로 했는데, HTTP/3에도 구글이 발표한 QUIC(Quick UDP Internet Connections) 프로토콜 기술이 적용된다. HTTP/2까지는 TCP 연결을 기반으로 하는데, HTTP over QUIC(HTTP/3)은 UDP 연결을 기반으로 한다.[1] 인터넷에서 일어나는 금융거래 및 전자상거래, 데이터 정보의 통신프로토콜의 발달로 개인의 프라이버시가 중요해짐에 따라서, 구글 크롬과 같은 웹브라우저들은 HTTP 웹사이트를 위험성이 있다고 경고문을 표시하고 있다. 국내기업 중 네이버㈜와 다음이 TTPS를 점차 확대하고있다.
역사[편집]
- 1996년 : 첫 상용화 버전인 HTTP/1.0 발표
- 1999년 : HTTP/1.1 발표
- 2015년 : HTTP/2 공식발표
특징[편집]
동작원리[편집]
응용계층에서 동작하는 HTTP는 TCP/IP(4계층)과 통신을 주고받기위해 소켓을 이용하게 된다. 사실 TCP 계층과 응용계층 사이에는 어떠한 계층이 존재하지 않는데, HTTPS 프로토콜은 이 두 개의 계층 사이에 SSL 계층이 포함되어 있다. 즉, HTTPS는 SSL 위에서 프로토콜이 실행된다. SSL은 일종의 독립적인 보안 계층으로 프로토콜을 실행하는데, 그 이유는 서로 다른 계층 간의 통신에서 소켓이 SSL과 연결되어 SSL이 보안 프로토콜 기능을 제안하기 때문이다.[2] 즉 SSL 프로토콜을 적용하면 SSL을 TCP로 인식하고 TCP는 정상적으로 통신이되어져 HPPTS 프로토콜을 실행하는데 아무 문제가 없다. HTTPS는 HTTP 헤더와 요청·응답 데이터를 비롯한 모든 메시지 내용을 암호화한다.
- SSL : 전송 계층을 보안하는 프로토콜로 컴퓨터 네트워크에 통신 보안을 제공하기 위해 설계된 암호 규약이다. TLS(Transport Layer Securtiy)라고도 부르며 이는 SSL이 표준화가 됨에 따라 이름이 변경되었다. 이 규약은 인터넷같이 TCP/IP 네트워크를 사용하는 통신에 적용되며, 통신 과정에서 전송계층 종단 간 보안과 데이터 무결성을 확보해준다. 이 규약은 웹 브라우징, 전자 메일, 인스턴트 메신저, VoIP 같은 응용 부분에 적용되고 있다. 처음 만들어진 1.0버전이 보안 문제로 취약하여 보안 문제를 극복하기 위해 새로운 버전을 출시했으며 결국 3.0 버전이 국제 인터넷 표준화 기구(IETF)에 의해 현재 구식(deprecate)으로 간주하여 TLS 1.0을 만드는데 참조가 되었다. 최종 갱신은 RFC 5246이고, 최종 갱신 버전은 넷스케이프에서 만든 SSL 표준을 바탕으로 했다.[3] 보안성을 가진 프로토콜로 인증기관을 통해 가고자 하는 서버의 인증서를 받게 되면 클라이언트의 정보를 암호화하여 전달하는 역활을 한다.
서버설정 및 암호화[편집]
HTTPS 연결을 허용하기에 클라이언트는 본인이 접속하는 서버가 신뢰할만한 서버인지 확인을 해야 하는 데 이 신원을 보증하기 위해서는 제3자의 입장인 인증기관(Certificate Authority)을 필요로 한다. HTTPS를 연결하기에 서버의 관리자는 공개키와 개인키를 만들고 신뢰할만한 인증 기간에 비용을 지불하고 공개키를 맡긴다. 인증기관은 암호화된 서버의 공개키를 다른 클라이언트와 서버에게 제공 하고 암호화된 공개키를 받은 서버는 해당 클라이언트에 이를 전달한다. 클라이언트는 인증기관을 통해 인증서 리스트를 탐색하게 되고 인증기관의 이름이 같게 되면 해당 인증기관은 공개키를 얻게 된다. 얻은 데이터를 본인만의 개인 키로 복호화한 후 정보를 받게된다.[4] HTTPS HTTPS 암호화 기술의 주요 특징은 다음과 같다.
- 기밀성 : 프라이버시로서, 인증되지 않은 제3자가 정보를 읽지 못하도록 정보를 보호하는 역할을 한다. 그 과정에서 듣거나 볼 수 있는, 보통 평문이라고 하는 읽을 수 있는 정보 형식을 암호문이라고 하는 뒤죽박죽 읽을 수 없는 데이터 형식으로 변환하는 작업을 거친다. 이 과정을 암호화라고 한다. 암호문을 다시 읽을 수 있는 평문으로 전환하는 반대의 과정을 복호화라고 한다. 정보를 암호화하고 복호화하는 방법에는 서버와 클라이언트 간에 공통된 공개키를 가지는 대칭키 암호화 방식, 인코딩과 디코딩이 다른(암호화하고 복호화하는데 사용되는 키가 다름을 의미) 공개키 암호화 방식 등이 존재한다.[5] 그렇기 때문에 암호화를 하여 사용자의 정보를 보호한다.
- 무결성 : HTTPS로 해결하는 또 다른 문제는 데이터 무결성이다. 즉, 전체 정보가 목적지에 도착했으며, 전송 중에 외부의 공격으로 변조되지 않았음을 보장한다. 정보가 잘 전송되었음을 보장하기 위해 메시지 다이제스트 알고리즘을 사용한다. 교환된 각 메시지의 메시지 인증 코드(message authentication codes, MAC)계산은 암호화 해싱 프로세스다. 즉 데이터가 잘 도착했는지 여부를 암호화된 메시지를 주고받음으로 확인한다.[5]
- 대칭키 : 서버와 클라이언트가 같은 키로 데이터를 통신한다. 흔히 암호화 알고리즘이라 부르는데, 암복호화 시 간편하고 드는 비용이 적다. 송수신자 양단은 하나의 키를 사용하여야 하며 이 대칭키는 하나의 키로 암호가 되어있기 때문에 보안상 유출이 된다면 암호의 내용이 해커에 의해 복호화된다는 치명적인 단점을 가지고 있다. 이를 보안을 유지하기 위해 나온 방법이 비대칭키 암호화 방식이다.
- 비대칭 키 : 공개키, 비공개키 방식을 가지고 데이터를 암복호화한다. 공개키로 암호화를 한다면 비공개키로 복호화를 해야 하고 마찬가지로 비공개키로 암호화를 한다면 공개키로 복호화를 해야 한다. 이 방식을 사용하여 두 개의 키 중 하나는 비공개키 혹은 개인키, 보안키(secure key)라고 하며 나머지를 공개키라고 부른다. 비공개키는 사용자 호스트만이 알고 읽을 수 있고 공개키는 다른 사용자에게 제공한다. 이러한 방식을 사용하여 공인 인증기관를 이용하여 인증서를 주고받아 원활한 HTTPS 동작을 수행한다.
인증서[편집]
클라이언트가 서버에 접속하기 위해서는 먼저는 본인이 접속하려는 서버가 인증이 보장되는지 판단을 내려야 하는데 이때 인증서에 등록된 정보를 가지고 인증기관에 공개키를 요청하게 된다. 이를 인증서를 통한 인증과정이라 한다. HTTPS는 보안 프로토콜로서 서버의 접속자와 서버 간의 주고받는 데이터의 암호화가 필수인데 이를 지정하고 인증서를 보관하는 인증기관은 신뢰성이 매우 우수해야 하며 정확한 절차로 인증이 된 공인 기업들만이 참여한다. 만약 웹 개발자가 서버를 만들 게되면 공개키를 믿을 수 있는 인증기관에 맡기게 된다. 인증기관은 공개키를 가지고 인증서를 만들고 이를 암호화하여 서버에게 전달한다. 인증서의 절차는 아래와 같은 방식으로 진행된다.
- 클라이언트는 서버로부터 받은 인증서가 인증기관에 의해 발급이 된 여부를 먼저 파악하기 위해 클라이언트 내에 저장된 인증기관 리스트를 컨펌한다.
- 컨펌이 된다면 해당 인증기관의 공개키로 인증서를 복호화 하고 이는 비공개키로 암호화됨을 의미한다.
- 이러한 방식으로 인증서를 전송한 서버를 신뢰하게 된다.
한마디로 말하면, 인증서의 역할은 클라이언트가 접속한 서버가 신뢰 할 수 있는 서버임을 보장하고 SSL 통신에 사용할 공개키를 클라이언트에게 제공하는 것이다.[6] 인증서를 발급한 기관명, 서비스 및 도메인 정보, 서버 측 공개키, 공개키의 암호화 방법 SSL 인증서 안에 기록되어 있다.
통신방법[편집]
컴퓨터와 컴퓨터간에 통신 방법에는 쓰리 핸드쉐이크(3-Handshake) 방식이 사용되며 핸드쉐이크 => 세션 => 세션종료로 진행한다. 핸드쉐이크는 악수라는 뜻인데, 사람사이에서도 먼저 악수를 하며 인사한다. 이를 통해 상대방의 분위기나 기분을 파악 할 수 있고 서로 원활한 커뮤니케이션을 할 수 있다.
- 핸드쉐이크 클라이언트와 서버는 서로 정보를 주고받기 전에 SSL 인증서를 먼저 주고받는다. 서로 간에 암호화 방식이 다를 수 있음으로 협상, 즉 동기화를(synchronization) 맺는 단계이다. 클라이언트가 암호화 방식을 서버에 발신하면 서버는 이를 받고 본인도 사용할 수 있는 암호화 방식을 택하여 다시 클라이언트에게 ACK(응답)와 SNY(동기화)를 보낸다. 이는 동기화를 하기 위한 과정이라고 할 수 있다. 클라이언트는 서버로부터 응답을 받게 되고 협상을 마치게 된다.
- 세션 : 실제 데이터가 오가는 동작 상태를 말한다. 앞서 암호화 방식에 대한 동기화를 했기 때문에 대칭키,비대칭키 방식으로 암호화된 정보를 주고받는다.
- 세션종료 : 주고받을 데이터가 없을 때에 세션을 종료하게 된다.
비교[편집]
HTTPS URL은 기본적으로 "https : //"로 시작하고 포트 443을 사용하지만 HTTP URL은 기본적으로 "http : //"로 시작하고 포트 80을 사용한다. SSL 인증서를 통해 사용자가 사이트에 제공하는 정보를 암호화하는데, 쉽게 말하면 데이터를 암호로 바꾸는 의미이다. 이렇게 전송된 데이터는 중간에서 누군가 훔쳐낸다고 하더라도 데이터가 암호화되어있기 때문에 해독할 수 없다. 한가지 예를 들면 512 비트(평균적으로 128비트 암호화)의 암호화라면, 2의 256승을 대입해야하며, 이것은 1,237,940,039,285 ....000(중략)이라는 기하급수적인 수를 대입해야 한다는 뜻과 같다. 그렇기 때문에 현재까지 나온 컴퓨터라 해도 적게는 몇백 년, 많게는 몇천 년 까지 계산을 해야 되는 문제가 발생한다. 그 외에도 HTTPS는 TLS 프로토콜을 통해서도 보안을 유지하고 TLS는 데이터 무결성을 제공하기 때문에 데이터가 전송 중에 수정되거나 손상되는 것을 방지하며, 사용자가 자신이 의도하는 웹사이트와 통신하고 있음을 입증하는 인증 기능도 제공한다. 서버-클라이언트 간의 데이터 송수신 시 암호화와 복호화 과정을 통해 데이터를 주고받기 때문에 HTTP보다 신뢰성이 뛰어나긴 하지만 여기서 발생하게 되는 데이터의 자원 소모가 발생하여 통신속도가 HTTP보다 느리다. 흔히 보안성이 낮아도 되는 온라인 뉴스나 기사에 HTTP를 사용하고 금융과 관련된 보안업무나 개인의 데이터 보호에 많이 사용된다.
문제점[편집]
HTTPS의 문제점은 사용 시 반드시 증명서를 구입해야 한다는 것이다. 증명서의 구입 비용이 부담되는 서비스나 개인 웹사이트의 경우 HTTP만 선택하기도 한다. 그리고 HTTPS를 사용할 경우 처리가 늦어지게 되는 단점이 있다. 그 이유는 클라이언트 요청 시, SSL에 필요한 통신이 추가되고, 암호화 복호화 계산을 하므로 서버나 클라이언트의 리소스를 추가적으로 소비하기 때문이다.[7] 인증기관은 매우 엄격하고 공인으로 인증된 기업이여햐만 한다. 신뢰성이 없는 인증기관이라면 인터넷 접속 시 SSL 인증서 발급은 물론 사용자와 서버가 서로 주고받는 정보가 도청, 간섭, 방해를 받아 데이터를 손실 할 수 있기 때문이다.
사이버보안 업체인 파이어아이(FireEye)는 최근 2019년 HTTPS를 이용한 피싱 이메일 공격이 17%증가 하였고, URL 기반 공격이 26%상승 했다고 이메일 위협 보고서를 발표했다. 일반적으로 피싱 이메일은 자격 증명 정보나 신용카드 정보를 탈취하기 위한 목적으로, 기존에 알고있는 연락처나 신뢰할 수 있는 회사를 사칭하여 이메일 수신인이 임베디드 링크를 클릭하도록 유도한다.[8]
이런 보안상의 문제를 해결하기 위해 정부는 HTTPS 사이트 접속 차단 조치를 내렸다. 이에대해 성균관대학교 지성우 법학 교수는 "온라인상의 불법 정보를 차단하는 일은 좋은 목적에서 시행한다 해도, 표현의 자유(인터넷의 속도성 자유성 개방성 제한)를 의식해야 한다" 고 말했다. 이런 논란으로 인해 반대하는 국민들과 정책을 시행하려는 정부 측의 의견이 엇갈리고 있다.[9]
물론 정부가 HTTPS 사이트 접속을 규제하긴 했다. 최근 기업의 서버/데이터 관리 또한 악성코드의 감염이 많이 일어나고 있고 구글은 HTTPS가 아니면 접근초차 못하게 한다. 하지만 현실은 불법 정보 사이트에 접속하면 http://warning.or.kr/ IP로 연결되어 경고문이 나오는 것을 심심치 않게 볼 수 있다. 이러한 정부의 적극적인 규제에 한때 DNS를 통한 사이트 우회, VPN 방식 등 여러 가지 어플들이 쏟아져 나왔고 해외와 달리 너무 엄격하다는 비난이 거센 적도 있었다. 그래도 과거보단 많은 불법 사이트가 규제되고 보안을 지키는 데 많은 도움이 되었다. 하지만 개인 SNS나 다크웹 을 보면 불법 정보, 동영상 등이 많이 있고 하나하나 IP를 추적해 규제를 가하는데는 어려움을 겪고 있다. IP주소는 굉장히 많기에 하나하나 규제를 가하는 것이 불가능해 보이긴 한다. 하지만 4차 산업혁명 시대에 더 많은 데이터와 통신을 요구하기에 앞으로 HTTPS의 암호화를 강화하고 적용하는 문제가 있다.
각주[편집]
- ↑ HTTP 나무위키 - https://namu.wiki/w/HTTP
- ↑ victolee, 〈(HTTPS)HTTPS와 SSL인증서〉, 《티스토리》, 2017-12-10
- ↑ 전송 계층 보안 위키백과 - https://ko.wikipedia.org/wiki/%EC%A0%84%EC%86%A1_%EA%B3%84%EC%B8%B5_%EB%B3%B4%EC%95%88
- ↑ 정아마추어 JEONG_AMATEUR, 〈Http와 Https 이해와 차이점 그리고 오해(?)〉, 《티스토리》, 2017-11-5
- ↑ 5.0 5.1 Vladislav Denishev, 〈HTTP에서 HTTPS로 전환하기 위한 완벽 가이드〉, 《웹엑추얼리》, 2018-11-13
- ↑ 코딩초보 여성계, 〈네트워크 - HTTP/HTTPS 차이점, HTTPS란?〉《티스토리》, 2019-08-01
- ↑ 손님1, 〈10. HTTPS란?〉, 《KENDRIC's BLOG》, 2016-04-12
- ↑ 길민권 기자, 〈2019년 1분기, HTTPS 이용 악성 URL 26% ↑, 피싱 시도 17% ↑〉, 《데일리시큐》, 2019-07-16
- ↑ 김평화 기자, 〈'https' 사이트 접속차단 논란, "'불법'에 국민동의 필요"〉, 《머니투데이》, 2019-06-07
참고자료[편집]
- HTTP 나무위키 - https://namu.wiki/w/HTTP
- victolee, 〈(HTTPS)HTTPS와 SSL인증서〉, 《티스토리》, 2017-12-11
- 전송 계층 보안 위키백과 - https://ko.wikipedia.org/wiki/%EC%A0%84%EC%86%A1_%EA%B3%84%EC%B8%B5_%EB%B3%B4%EC%95%88 전송 계층 보안
- 정아마추어 JEONG_AMATEUR, 〈Http와 Https 이해와 차이점 그리고 오해(?)〉, 《티스토리》, 2017-11-5
- Vladislav Denishev, 〈HTTP에서 HTTPS로 전환하기 위한 완벽 가이드〉, 《Smashing Magazine》, 2018-11-13
- 코딩초보 여성계, 〈네트워크 - HTTP/HTTPS 차이점, HTTPS란?〉《티스토리》, 2019-08-01
- 손님1, 〈10. HTTPS란?〉, 《KENDRIC's BLOG》, 2016-04-12
- 길민권 기자, 〈2019년 1분기, HTTPS 이용 악성 URL 26% ↑, 피싱 시도 17% ↑〉, 《데일리시큐》, 2019-07-16
- 김평화 기자, 〈'https' 사이트 접속차단 논란, "'불법'에 국민동의 필요"〉, 《머니투데이》, 2019-06-07
- 카피켓, 〈카피켓의 쉬운 암호학〉, 《티스토리》, 2007-12-20
- jm, 〈TCP-(3way handshaking & 4way handshaking)〉, 《네이버 블로그》, 2020-1-28
같이 보기[편집]
