HTTPS(HTTP + Secure)
HTTP는 인터넷에서 데이터를 주고 받을 수 있는 통신 프로토콜인데, HTTPS는 거기에 보안 기능이 추가된 것이다. HTTPS는 Hyper Text Transfer Protocol Secure Socket layer 의 약자이다. HTTP over SSL(TLS), HTTP over Secure라고 부르기도 한다. HTTP 프로토콜 내용을 암호화하여 보안성을 추가하는데, HTTPS는 HTTP 요청을 SSL 혹은 TLS라는 알고리즘을 이용해, HTTP 통신을 하는 과정에서 내용을 암호화하여 데이터를 전송한다.
여기서 SSL과 TLS는 무엇일까?
SSL과 TLS는 모두 웹 서버와 사용자의 웹 브라우저 간 통신을 암호화 하는데 사용되는 프로토콜이다. 공개 키와 개인 키를 교환하여 보안 세션을 생성하여 통신을 암호화하는 방식을 사용한다. TLS는 MAC 함수 생성을 위해 다른 암호화 알고리즘을 사용하며, 이는 이전 버전의 SSL 보다 많은 경고 코드를 포함하고 있다.
SSL(Secure Sockets Layer)은 보안 소켓 계층 이라는 뜻으로 인터넷을 통해 전달되는 정보 보안의 안전한 거래를 허용하기 위해 Netscape 사에서 개발한 인터넷 통신 규약 프로토콜이며, TLS(Transport Layer Security)는 SSL 3.0을 기초로 해서 IETF가 만든 프로토콜로 이는 SSL3.0을 보다 안전하게 하고 프로토콜의 스펙을 더 정확하고 안정성을 높이는 목적으로 고안되었다. 즉 TLS가 SSL의 단점을 더욱 보완하여 나온 프로토콜이라는 것.
SSL과 TLS 두 가지 프로토콜은 TCP/IP 네트워크를 사용하는 통신에 적용되며, 통신 과정 에서 전송계층 종단간 보안과 데이터 무결성을 확보 할 수 있게 해준다.
SSL과 인증기관(CA)는 어떤 관계가 있을까?
SSL은 Certificate Authority(CA)라 불리는 서드 파티로부터 서버와 클라이언트의 인증을 하는데 사용된다.
- [웹브라우저] SSL로 암호화된 페이지를 요청하게 된다. (일반적으로 https://가 사용된다)
- [웹서버] Public Key를 인증서와 함께 전송한다.
- [웹브라우저] 인증서가 자신이 신용있다고 판단한 CA(일반적으로 trusted root CA라고 불림)로부터 서명된 것인지 확인한다. (역주:Internet Explorer나 Netscape와 같은 웹브라우저에는 이미 Verisign, Thawte와 같은 널리 알려진 root CA의 인증서가 설치되어 있다) 또한 날짜가 유효한지, 그리고 인증서가 접속하려는 사이트와 관련되어 있는지 확인한다.
- [웹브라우저] Public Key를 사용해서 랜덤 대칭 암호화키(Random symmetric encryption key)를 비릇한 URL, http 데이터들을 암호화해서 전송한다.
- [웹서버] Private Key를 이용해서 랜덤 대칭 암호화키와 URL, http 데이터를 복호화한다.
- [웹서버] 요청받은 URL에 대한 응답을 웹브라우저로부터 받은 랜덤 대칭 암호화키를 이용하여 암호화해서 브라우저로 전송한다.
- [웹브라우저] 대칭 키를 이용해서 http 데이터와 html문서를 복호화하고, 화면에 정보를 뿌려준다.
인증에서 HTTPS 프로토콜을 사용해야만 하는 이유는 HTTP보다 상대적으로 안전한 방법이고, 데이터 제공자의 신원을 보장받을 수 있기 때문이다.
데이터 제공자의 신원을 확인하고 보장받는 게 인증에서 중요한 이유는 다음과 같다.
- 클라이언트는 데이터 제공자가 제공해준 데이터를 사용할 수밖에 없다. 클라이언트는 서버에 데이터 요청을 하고 이후 받은 데이터를 이용해서 화면을 렌더링하는 등의 작업을 해야한다.
- 그렇기 때문에 요청 및 응답을 중간에서 가로채는 중간자 공격에 취약하다. '중간자 공격'은 클라이언트와 서버 사이에서 공격자가 서로의 요청, 응답의 데이터를 탈취 및 변조하여 다시 전송하는 공격이다.물론 중간자 공격으로 인해 이런 추가 데이터 또한 변조할 수 있다. 따라서 해당 데이터를 암호화시키는 작업이 필요한 것이다.
중간자 공격이란 무엇일까?
중간자 공격은 장치(PC/전화)와 웹 서버 사이에서 데이터 전송이 이루어지는 동안 기술과 도구를 사용하여 두 시스템 사이의 데이터를 가로채는 것을 의미한다. 4가지의 방식이 있는데 스니핑, 패킹주입, 세션 하이재킹 공격, SSL 스트리핑이 있다.
스니핑
스니핑 또는 패킷 스니핑으로도 불리는데, 시스템/네트워크에서 들어오고 나가는 데이터 패킷을 캡쳐하는데 사용되는 기술이다. 네트워크에서의 패킷 스니핑은 도청과 비슷하다. 이 스니핑이라는 것이 올바르게 사용되면 합법적이고 보안 목적으로 사용되는데 다른 목적으로 사용되면 중간자 공격으로 사용되는 것이다.
패킷 인젝션
공격자가 일반 데이터와 함께 악의적인 데이터를 주입하는 것이다. 사용자에게는 합법적 통신 스트림의 일부로 제공되기때문에 파일/멀웨어 프로그램인지 인식을 하지 못한다. 중간자 공격과 서비스 거부 공격에서 흔히 볼 수 있는 요소이다.
세션 하이재킹 공격
두 시스템 간 연결이 활성화된 상태를 가로채는 것이다. Session Expired라는 오류가 발생하게 만든다. 세션을 일상적인 것으로 생각해보면 은행계좌에 로그인하고 로그 아웃하는데 걸리는 시간으로 볼 수 있는데, 이러한 세션이 해커들의 표적이 되고, 데이터들을 제어하는 등 다양한 방법으로 공격을 실행한다.
SSL 스트리핑
SSL/TLS 연결을 차단하여 프로토콜을 보안성이 있는 HTTPS에서 안전하지 않은 HTTP로 전환시켜버린다.
데이터가 중간에 다른 도메인을 거쳐서 전달되기 때문에 서버가 "해당 데이터는 https://example.com 도메인에서 제공되었습니다." 라는 추가데이터를 응답객체에 실어 보낸다면 '중간자 공격'으로 인해 다른 도메인에서 데이터를 받은 클라이언트는 데이터를 제공한 도메인과 전달받은 내용의 도메인을 비교하여 '중간자 공격'이 존재하는지 아닌지 확인할 수 있게 된다. 물론 중간자 공격으로 인해 이런 추가 데이터 또한 변조될 수 있다. 이런 이유들 때문에 해당 데이터를 암호화 시키는 작업이 꼭 필요한 것이다.
암호화
HTTPS 프로토콜의 특징 중 하나는 암호화된 데이터를 주고받기 때문에, 중간에 인터넷 요청이 탈취되더라도 그 내용을 알아볼 수 없다. 기존 HTTP 프로토콜은 요청 및 응답을 탈취한다면 프로그램을 이용하여 아래와 같이 해당 요청으로 전달되는 데이터의 내용을 확인할 수 있다. 아래 사진은 데이터를 전송하는 요청을 'wireshark'라는 패킷 분석 프로그램을 이용하여 캡처한 사진이다.
하지만 데이터를 암호화하여 전송하는 HTTPS 프로토콜을 사용한다면 비밀번호와 같은 중요한 데이터가 유출될 가능성이 HTTP 프로토콜보다 현저히 적어지게 된다. 아래 사진은 위 사진에서 똑같은 요청을 프로토콜만 HTTPS로 변경했을 때의 데이터를 캡처한 사진
사진에서 볼 수 있듯 내용이 암호화되어 전송되기 때문에 정확한 키로 복호화 하기전까지는 어떤 내용인지 알 수 없다.
인증서
HTTPS 프로토콜의 또 다른 특징 중 하나는 브라우저가 응답과 함께 전달된 인증서 정보를 확인할 수 있다는 점이다. 브라우저는 인증서에서 해당 인증서를 발급한 CA 정보를 확인하고 인증된 CA가 발급한 인증서가 아니라면 아래와 같이 화면에 경고창을 띄워 서버와 연결이 안전하지 않다는 화면을 보여준다.
이렇게 브라우저는 인증서의 도메인과 데이터를 제공한 제공자의 도메인을 비교할 수 있기 때문에 인증서의 도메인 정보와 데이터 제공자의 도메인 정보가 다른 '중간자 공격'을 감지하여 보안 위협으로부터 사용자 및 사용자의 데이터를 보호할 수 있다.
또한 이런 경고를 직접 보여줌으로써 브라우저들은 인증된 CA가 발급한 인증서를 이용하여 데이터를 제공하는 안전한 서버를 사용할 수 있게 사용자를 유도한다.
'개발 R.I.P.' 카테고리의 다른 글
9.08 Dev.Feedback (Cookie) (2) | 2021.09.08 |
---|---|
9.07 Dev.Feedback (토큰 기반 인증) (0) | 2021.09.07 |
9.05 Dev.Feedback(조합, 순열, 중복순열, 최대공약수, 최소공배수 Template) (0) | 2021.09.05 |
9.03 Dev.Feedback (Mongo DB #1) (0) | 2021.09.03 |
8.26 Dev.Feedback (SQL) (0) | 2021.08.26 |