오늘의 주제 http 와 https 에 대한 내용은 http에한 개념적인 내용은 생략하고, http를 알고 있다는 가정하에 설명을하도록 하겠습니다.
http 에 대한 내용이 궁금하시거나? 잘 모르시겠다면 아래에 제가 정리한 블로그 글을 읽고 오시면 좋을 거 같습니다
https://devnuts.tistory.com/71?category=1003683
https://devnuts.tistory.com/72?category=1003683
이 HTTP와 HTTPS 차이에 대하여 설명하기 위한 대표 키워드는 보안 입니다.
HTTP는 보안적으로 안전한가?
HTTP 통신은 클라이언트와 서버 간의 통신에 있어서 별다른 보안 조치가 없기 때문에 만약 다른 누군가 네트워크 신호를 가로챈다면? HTTP의 내용을 그대로 외부로 노출될 수 있습니다.
중요한 정보가 없는 소규모의 프로젝트라면 큰 문제가 되지 않겠지만, 고객의 개인정보나 비밀을 취급하는 대규모의 서비스 라면? 이 부분이 보안적 허점이 될 것입니다.
이런 문제를 해결하기 위해 등장한 것이 https 입니다.
마지막 s는 over Secure socket Layer 의 약자로 보안이 강화된 버전을 말합니다.
지난 2014년 구글에서 HTTP를 HTTPS로 바꾸라고 권고하였습니다.
그 전까지는 전자상거래 페이지가 있는 웹사이트에만, 다소 번거로운 HTTPS를 사용하고 있었습니다.
구글 측에서는 대가없이 HTTP -> HTTPS 바꾸라하지 않았습니다.
HTTPS 전환을 장려하기 위해서 HTTPS를 사용하는 웹사이트에 대해서 검색 순위 결과에 약간의 가산점을 주겠다고 발표했습니다. 이는 사실상 HTTP를 사용하는 웹사이트에겐 벌점을 주는 것과 마찬가지였습니다.
HTTPS
데이터 암호화가 추가된 프로토콜입니다. HTTP는 80포트를 사용하지만, HTTPS는 443포트를 사용합니다.
HTTPS의 중요한 역할은 크게 3가지로 볼 수 있습니다.
- 클라이언트가 서버로 보내는 정보들을 제 3자가 볼 수 없습니다.
- 접속한 사이트가 신뢰할만한 사이트인지 알려주는 역할을 합니다.
- 통신 내용의 악의적인 변경을 방지할 수 있습니다.
HTTPS 의 암호화 프로세스
HTTPS는 대표적으로 두 가지의 암호화 방식을 이용한다고 말할 수 있습니다.
- 대칭키 암호화
- 비대칭키 암호화
대칭키 암호화
- 클라이언트와 서버가 동일한 키를 사용해 암호화 / 복호화를 진행합니다.
- 키가 노출되면, 매우 위험하지만 연산속도가 빠릅니다.
키란 암호화를 진행할 때, 사용되는 비밀번호와 같은 역할을 합니다.
이 키에 따라 암호화된 결과가 달라지기 때문에, 키를 모르면 복호화 또한 할 수 없습니다.
대칭키는 암호화에 사용되는 키와 복호화에 사용되는 키가 동일한 암호화 기법 입니다.
대칭키의 명확한 단점이 존재합니다.
대칭키는 암호화와 복호화를 하기 위해 상대가 복호화 시킬 수 있게 하기 위해서 적어도 한 번은 이 대칭키의 공유가 이루져야 합니다.
이때 키를 교환하는 부분이 명확한 단점이 됩니다. 이러한 키를 교환 도중에 키가 탈취될 수 있는 문제도 있고,
사람이 증가할수록 전부 따로 키를 교환하기 때문에 관리해야할 키가 방대하게 많아집니다.
이러한 단점을 해결하기 위해선 여러가지 방법들이 존재합니다.
- 키의 사전 공유에 의한 해결
- 키 배포센터에 의한 해결
- Diffie-Hellman 키 교환에 의한 해결
- 공개키 암호에 의한 해결
대칭키 장단점
- 장점 : 수행 시간이 짧습니다.
- 단점 : 안전한 키 교환 방식이 요구됩니다. 또한 사람이 증가할수록 키 관리가 어려워집니다.
대칭키 대표 알고리즘
- SEED : 공인인증서의 암호화
- DES
- 3DES
- AES
- ARIA
- ChaCha20 : 최근 주목받고 있는 암호인
비대칭키 암호화
- 1개의 쌍으로 구성된 공개키와 개인키를 암호화 / 복호화 하는데 사용합니다.
- 키가 노출되어도 비교적 안전하지만, 연산 속도가 느립니다.
비대칭키 암호화는 공개키와 개인키 암호화 방식을 이용해 암호화를 합니다.
공개키와 개인키는 서로를 위한 한 쌍의 키로 생각하시면 됩니다.
- 공개 키 : 모두에게 공개가 가능한 키
- 개인 키 : 나만 가지고 알고 있어야 하는 키
위의 설명한 대칭키의 키 교환 문제를 해결하기 위해 등장한 것이 이 암호화 방식인데, 이름 그대로 키가 공유되어 있기 때문에 키를 교환할 필요가 없어집니다.
따라서, 공개 키는 공개가 되어있기 때문에 키 교환이나 분배를 할 필요가 없습니다.
중간 공격자가 B의 공개키를 얻는다고 하여도, B의 개인키로만 복호화가 가능하기 때문에 기밀성을 제공하며
개인키를 가지고 있는 수신자만이 암호화된 데이터를 복호화할 수 있으므로, 일종의 인증기능도 제공합니다.
비대칭키 장단점
- 키 분배가 필요 없습니다. 또한 기밀성/인증/부인방지 기능을 제공합니다.
- 대칭키 암호화 방식보단 속도가 느립니다.
비대칭키 대표 알고리즘
- Diffie Hellman : 최초의 공개키 알고리즘, 위조에 취약
- RSA : 대표적 공개키 알고리즘
- DSA : 전자서명 알고리즘 표준
- ECC : 짧은 키로 높은 암호 강도, 빠른 구현 가능 PDA, 스마트폰등에 사용
HTTPS 프로세스
HTTPS 는 대칭키, 비대칭키 암호화 둘 다 사용하여, 빠른 연산속도와 안정성을 모두 얻습니다.
HTTPS 연결 과정에서는 먼저 서버와 클라이언트 간에 세션키를 교환합니다.
여기서 세션키는 주고 받는 데이터를 암호화하기 위해 사용되는 대칭키입니다.
데이터 간의 교환에는 빠른 연산 속도가 필요하므로, 세션키는 대칭키로 만들어집니다.
문제는,
이 세션키를 클라이언트와 서버가 어떻게 교환할 것이냐입니다.
이 과정에서 비대칭키가 사용됩니다.
정리하자면, 처음 연결을 성립하여 안전하게 세션키를 공유하는 과정에서 비대칭키를 사용되고, 이 후에 데이터를 교환하는 과정에서 빠른 연산 속도를 위해 대칭키를 사용하게 되는 것입니다.
HTTPS 의 SSL 발급 과정
추가로 알아야할 분이 있습니다. 서버가 비대칭키를 발급받는 과정입니다.
서버는 클라이언트와 세션키를 공유하기 위한 공개키를 생성해야 하는데, 일반적으로 인증된 기관(Certificate Authority)에 공개키를 전송하여 인증서를 발급받습니다.
1. (서버) 서버의 공개키와 비밀키를 생성합니다.
2. (서버) 인증서를 발급 받기 위해, 서버는 CA 에 아래의 정보를 전달합니다.
- 1번에서 생성한 서버의 공개키
- 서버의 각종 정보
3. (CA) 2번에서 서버로부터 받은 정보들, 공개키를 담아 SSL 인증서를 발급합니다.
4. (CA) 3번에서 만든 인증서를 암호화하기 위해, CA의 공개키와 비밀키를 생성합니다.
5. (CA) CA의 비밀키를 이용해, SSL 인증서를 암호화 합니다.
6. (CA) 5번에서 암호화한 SSL 인증서를 다시 서버에 전달합니다. (인증서 발급 완료)
'CS > Network' 카테고리의 다른 글
HTTP1 vs HTTP2 (두 프로토콜의 차이) (0) | 2022.04.18 |
---|---|
HTTP 란? (1) | 2022.04.17 |