인터넷을 사용하다 보면 어떤 URL이던 간에 http으로 시작하는 것을 확인 할 수 있다.
또한 URL 중에서도 http 로 시작하는 경우가 있고 https 로 시작하는 경우가 있을 것이다.
이 두가지의 개념은 무엇이고 차이점은 무엇일까?
먼저 URL의 개념부터 간단하게 설명하도록 하겠다.
URL은 웹 상에서의 주소체계이다.
웹에서 보여지는 한 화면은 파일로 구성되어 있는 것인데,
웹에 존재하는 파일을 다른 파일과 구별하는 식별자라고 생각하면 쉽다.
더 쉽게 이해하기 위해 URL의 구성을 살펴보도록 하겠다.
예를 들어 만용의 블로그 URL로 예시를 들어보자면
https://miny-dev.tistory.com/4
https : 프로토콜
miny-dev.tistory.com : 호스트 주소 (지난 번 포스팅했던 도메인, IP 주소이다.)
/4: 경로 (파일의 경로라고 생각하면 쉽다.)
로 구성되어 있다.
그리고 여기서의 프로토콜인 부분이 이번 포스팅에서 중점적으로 다룰 키포인트이다.
프로토콜은 무엇일까?
간단히 설명하자면 어떠한 통신을 하고자 할 때 교환되는 데이터의 형식을 정의하는 규칙의 집합이라고 생각하면 된다.
즉, 위의 예시로 들었던 URL로 설명을 하자면 클라이언트에서 웹 서버로 https 요청을 하겠다라는 정의이다.
HTTPS 를 이해하기 위해서는 HTTP의 개념과 동작원리를 먼저 알아야한다.
HTTP를 개념적인 측면에서 설명하자면
Hyper Text Transfer Protocol 의 약자로 서버와 클라이언트 간의 데이터 통신을 위한 프로토콜이다.
HTTP는 80번 포트에서 서비스를 대기하고 있다가
클라이언트에서 TCP 80번 포트를 연결해 어떤 정보 요청이 이루어지면 서버에서 응답해주는 방식이다.
이렇게 글로만 봐서는 이해하기 쉽지 않을 것이다.
그렇다면 HTTP의 동작과정은 어떻게 이루어지는 것일까?
HTTP의 동작과정을 간단하게 설명하면 이러하다.
1. 클라이언트에서 웹 서버로 Connect 요청, 서버에서 요청 수락
2. 클라이언트에서 HTTP 요청 메세지 Request
3. 서버에서 HTTP 요청에 대한 응답 Response
4. 전달완료 후 Connect 끊김 (Stateless : 무상태, 통신에 대한 정보나 상태 보관 x)
클라이언트에서 HTTP Request를 할 때는 Requset 객체를 통해 요청하게 된다.
Request 객체는 시작줄, 헤더, 본문으로 구성되어있다.
어떤 정보를 어떤 곳에서 어떤 방식을 이용해서 요청하는 지에 대한 정보가 있다고 생각하면 된다.
서버에서는 해당 Request 객체에 대한 정보를 확인하고 요청한 정보를 담아 Response 객체에 담아 응답한다.
HTTP는 연결 상태를 유지하지 않는 비연결성 프로토콜로 요청된 정보를 응답하면 연결을 끊고 통신한 정보나 상태를 삭제한다.
그럼 HTTPS는 왜 생겨나게 된걸까? HTTP와 HTTPS의 차이점은 무엇일까?
데이터의 다양화에 따라 다양하고 많은 데이터가 HTTP를 통해 통신되고 사용되었는데, 보안에 대한 문제점이 발생했다.
통신 중인 데이터를 가로채서 어떤 데이터가 주고 받아졌는지 확인 할 수 있기 때문인데,
이를 방지하기 위해 HTTPS가 만들어졌다.
HTTPS는 클라이언트가 접속하려는 서버가 신뢰할 수 있는 서버인가? 를 먼저 확인하고
통신에 필요한 정보들이 노출되거나 변경되는 것을 방지함으로서 HTTP 보안의 문제점을 해결했다.
개념적으로 설명하자면 HTTPS는 Secure를 추가해 보안이 강화된 HTTP 라고 생각하면 쉽다.
그럼 어떻게 보안을 강화했다는 걸까?
바로 통신 내용을 암호화해서 이용한 것이다.
위의 그림처럼 사용자가 어떤 정보를 보낼 때, 해당 정보를 암호화하는 것이다.
그럼 해당 정보를 가로채더라도 암호화된 정보를 보기 때문에 어떤 정보를 의미하는 것인지 알 수 없다.
그럼 암호화는 어떻게 이루어지는 것이고 암호화된 정보는 어떻게 복호화되는 걸까?
암호화 방식에는 공개키 암호화 방식과 대칭키 암호화 방식이 있다.
공개키 암호화 방식이란 암호화한 정보를 복호화할 수 있는 키가 서로 고정되어 사용되는 것이다.
A키로 암호화한 정보면 B키를 이용해야만 복호화가 가능하다.
B키로 암호화한 정보면 A키를 이용해야만 복호화가 가능하다.
일반적으로는 A키와 B키 중, 하나를 개인키라고 칭하고 이는 사용자만 가지고 있는다.
그리고 나머지 다른 키를 공개키라고 칭하고 통신이 필요한 다른 사용자에게 제공하는 것이다.
이렇게 암호화된 정보는 A키, B키가 없다면 암호화, 복호화를 할 수 없다.
두번째 방식으로는 대칭키 암호화 방식이 있다.
대칭키 방식은 동일한 키로 암호화, 복호화를 가능하게 하는 것이다.
대칭키는 매번 랜덤으로 생성되기 때문에 안전하고 공개키보다 빠른 통신이 가능하다.
이러한 암호화 방식을 적용하기 위해서는 SSL (Secure Socket Layer) 프로토콜을 이용해야 한다.
즉, HTTPS는 인터넷 상에서 정보를 암호화하는 SSL 프로토콜을 이용해서
클라이언트와 서버가 암호화된 데이터를 주고 받는 프로토콜이라고 할 수 있다.
그럼 HTTPS를 이용하기 위해서는 SSL 프로토콜을 이용해야 하는 것인데,
키에 대한 정보는 어디에 저장되어 있는 것이며 어떻게 통신되는 것일까?
SSL 프로토콜을 적용하기 위해서는 인증서를 발급해 서버에 적용시켜야 한다.
이 인증서를 통해 사용자가 접속한 서버의 안정성을 보장하는 것이다.
인증서를 발급하는 기관을 CA(Certificate Authority) 라고 부른다.
다시 말해, CA 란 공개키와 공개키를 사용할 서버의 연결을 보장하는 기관이며
이를 통해 인증서를 발급받아야 SSL 프로토콜 적용이 가능하다는 뜻이다.
(반드시 CA를 통해 인증서를 발급받아야 하는 것은 아니다.)
동작 과정을 설명하자면
서버에서 공개키와 개인키를 생성해 CA 인증 기관에 해당 사이트 정보와 공개키를 제공한다.
인증 기관에서는 해당 정보를 검증하고 인증기관의 개인키로 제공된 정보를 암호화해서 인증서를 발급한다.
그리고 인증기관은 웹 브라우저에 인증기관의 공개키를 제공한다.
만약 어떤 사용자가 웹 브라우저에 접속하게 되면 해당 서버는 인증 기관에서 발급받은 인증서를 웹 브라우저로 보낸다.
이때 인증서는 인증 기관의 개인키로 암호화가 되어있다.
웹 브라우저는 해당 인증서의 공개키를 가지고 있기 때문에 인증서를 복호화하여
해당 서버의 사이트 정보와 공개키 정보를 알 수 있게 된다.
이 과정을 통해 서버로부터 온 요청이 보안상으로 안전한 요청인지 확인하는 것이다.
그 이후에는 대칭키를 새로 생성해 얻어 낸 서버의 공개키로 대칭키를 암호화, 사이트의 개인키로 대칭키를 복호화하여
데이터를 주고 받음으로서 안전한 통신이 이루어진다.
그 이후의 웹 브라우저와 서버와의 통신은 대칭키로 이루어진다.
HTTPS는 모든 사이트에서 사용되면 서버 과부하 또는 속도 저하 등의 현상이 나타날 수 있기 때문에
개인정보 같은 중요한 데이터의 통신이 필요한 경우에만 사용하는 것이 좋다.
하지만 HTTPS를 지원하는 사이트라고 해서 모두 안전한 것은 아니다.
CA 인증 기관에서만 인증서를 발급해야 하는 것은 아니기 때문이다.
또한 CA 인증 기관이라고 해서 모두 신뢰할 수 있는 것도 아니다.
이런 경우 URL이 https로 시작되지만
"주의 요함", "안전하지 않은 사이트" 등의 알림이 오기도 한다.
하루에도 수없이 많은 사이트를 접속하게 되지만
URL이 http로 시작되는 지, https로 시작되는 지 보지 않는 경우가 허다하다.
모든 사이트가 개인정보로부터 안전한 것은 아니다.
아는 만큼 보이는 것이기 때문에 자신이 이용하려고 하는 사이트가 안전한지 아닌지 확인하기 위해서
한 번쯤은 알고 넘어가기 좋은 내용인 듯 하다.
Reference
https://rachel-kwak.github.io/2021/03/08/HTTPS.html
'개발일기' 카테고리의 다른 글
| 로그인, 로그아웃의 동작원리? 쿠키와 세션, 웹 스토리지 이론 (0) | 2023.10.15 |
|---|---|
| 이클립트(Eclipse) 다운로드 및 설치 방법 (0) | 2023.10.15 |
| 방화벽이란? ip주소, 포트번호에 대한 이론적 내용 정리 (1) | 2023.10.15 |
| WEB 서버와 WAS(Web Application Server)의 차이 (1) | 2023.10.15 |
| DNS(Domain Name System) 개념 및 동작 원리 (1) | 2023.10.15 |