목차
HTTP vs HTTPS
HTTP(HyperText Transfer Protocol)?
- 서로 다른 시스템들 사이에서 통신을 주고받게 하는 가장 기본적인 프로토콜입니다.
- 서버에서 브라우저로 데이터를 전송하는 용도로 가장 많이 사용합니다.
문제점: 암호화를 하지 않는다.
한편, HTTP는 서버에서 브라우저로 전송되는 정보가 암호화가 되지 않는다는 문제점을 가지고 있습니다.
그래서 누군가가 데이터를 전송하는 도중에 쉽게 가로챌 수 있습니다.
HTTPS(HyperText Transfer Protocol Secure)?
- HTTP에 SSL(보안 소켓 계층, Secure Sockets Layer)을 사용한 프로토콜입니다.
- HTTP에서 데이터가 암호화되지 않는 문제점을 SSL을 활용하여 해결했습니다.
- SSL은 서버와 브라우저 사이(또는 두 서버 사이)에 검증된 연결을 도와주고, 전송되는 데이터를 암호화하여, 서버와 브라우저가 보안에 민감한 데이터를 주고 받을 때 해당 정보가 도난당하는 것을 막아주는 표준 기술입니다.
- 참고로, HTTPS는 HTTP 자체를 암호화하는 것은 아닙니다. HTTP를 사용해서 운반하는 데이터, 즉 HTTP message body를 암호화합니다. 이때, HTTP header는 암호화되지 않습니다.
- 아래 그림처럼 HTTP 통신이 SSL Layer에서 이루어지는 것을 HTTPS라고 합니다.
HTTP vs HTTPS: 전송 과정
HTTP 전송 : 암호화 X
- HTTP로 전송하는 데이터는 데이터 원본 그 자체입니다. (암호화를 진행하지 않습니다.)
- 따라서, 해커가 중간에 데이터를 가로챈다면, 해당 데이터를 바로 읽을 수 있습니다.
HTTPS 전송 : 암호화 O
- 반면, HTTPS는 HTTP와 달리 데이터를 암호화하여 전송합니다.
- 따라서 해커가 중간에서 데이터를 가로채도 암호화된 데이터를 해석할 수 없게 됩니다.
SSL / TLS
❕참고
SSL의 업그레이드 버전이 TLS(Transport Layer Security)입니다. 넷스케이프 사에 의해서 발명된 SSL이 폭넓게 사용되다가 표준화 기구인 IETF의 관리로 변경되면서 TLS라는 이름으로 바뀌게 되었습니다. 일반적으로 SSL과 TLS는 동일한 용어이므로 어떤 단어를 선택해도 무방합니다. 현재 글에선 SSL을 선택해서 작성하도록 하겠습니다.
SSL(Secure Sockets Layer)?
- Netscape 회사에서 웹 서버와 웹 브라우저간의 보안을 위해 만든 프로토콜입니다.
- 공개키/개인키, 대칭키 방법을 혼합해서 사용합니다.
- 두 방법 중 하나의 방법만을 채택하지 않고 두 방법을 혼합해서 사용하는 이유는 두 방법의 단점을 보완하기 위해서입니다.
더 자세히 SSL을 알아보기 전에, 먼저 공개기/개인키, 대칭키 방법을 알아봅시다.
공개키 vs 대칭키
대칭키
동일한 키로 데이터 암호화 및 복호화를 진행합니다.
(같은 키로 복호화와 암호화를 진행하기 때문에 키가 대칭된다는 뜻으로 대칭키라고 부릅니다.)
대칭키는 같은 키로 암호화 및 복호화를 진행하기 때문에, 누구든지 대칭키만 가지고만 있다면, 암호화된 데이터를 복호화할 수 있습니다.
위의 그림과 같이 서버와 브라우저는 암호화된 데이터를 전송 하기 전에 대칭키를 주고 받습니다.
이떄, 해커가 대칭키를 도난한다면 암호화된 데이터를 쉽게 풀 수 있습니다.
절차
대칭키는 다음과 같은 절차를 따릅니다.
- 키 생성 : 암호화와 복호화에 사용할 대칭키를 생성합니다. 이 키는 무작위하고 안전하게 생성되어야 합니다.
- 암호화 : 데이터를 대칭키를 이용하여 암호화합니다. 암호화 과정은 간단히 말하면 데이터를 일정한 알고리즘을 사용하여 뒤섞는 과정이며, 암호화된 데이터는 알아볼 수 없는 형태로 변환됩니다.
- 초키 키 교환 : 데이터를 주고 받기 전에, 서버와 브라우저 간에 대칭키를 공유해야 합니다. 이때 이 키를 안전하게 전달해야 합니다. 그렇지 않으면, 누구든지 키를 도난해 키를 사용하여 데이터를 복호화할 수 있기 떄문에 보안에 취약해집니다.
- 세션 유지 (암호화, 복호화) : 서버와 브라우저는 초기에 교환한 대칭키를 사용하여 세션동안 데이터를 주고 받습니다. 대칭키를 사용하여 암호화 및 복호화하는 작업을 포함합니다.
- 세션 종료 : 세션이 종료되면, 사용된 대칭키는 폐기되고, 새로운 세션에서는 다시 초기 키 교환을 통해 새로운 대칭키를 설정합니다.
이렇게 함으로써, 대칭키를 데이터 전달할때마다 매번 전달하지는 않습니다.
하지만, 그럼으로써 초기 키 교환 단계에서의 보안이 매우 중요하며, 이를 위해 공개키 암호화 기술이나 안전한 키 교환 매커니즘을 사용하는 것이 일반적입니다.
정리
- 대칭키는 비교적 간단한 알고리즘을 사용하기 때문에, 데이터를 빠르게 암호화하고 복호화할 수 있어 처리 속도가 빠르다는 장점이 있다.
- 반면, 키 관리 문제점이 있다. 대칭키를 전달하는 과정에서 도난의 위험이 있기 때문에 이러한 문제점을 해결하기 위해 공개키 암호화 방식이 개발되었다.
공개키
- 공개키 방식은 두 개의 키, 공개키(public key)와 개인키(비공개 키, private key)를 가집니다.
- 공개키로 암호화하면 개인키로 복호화할 수 있고, 개인키로 암호화하면 공개키로 복호화할 수 있습니다.
(암호화에 사용하는 키와 복호화에 사용하는 키가 다르므로 비대칭키라고도 부릅니다.) - 공개키로 암호화된 데이터는 오로지 개인키로만 복호화할 수 있기 때문에, 누구든지 공개키를 가져도 상관이 없습니다.
- 공개키는 단어 그대로 공개가 되도 상관이 없는 키이기 떄문에 중간에 해커가 가로채도 문제가 되지 않습니다.
과정
1. A가 B에게 접속을 요청하면, B는 A에게 공개키를 전달합니다.
- 공개키는 전달과정에서 노출이 되어도 안전합니다.
2. A는 공개키로 데이터 암호화를 진행합니다.
3. A는 암호화된 데이터를 B에게 전송합니다.
3. B는 암호화된 데이터를 자신의 개인키로 복호화하여 원본데이터를 전송받습니다.
이 방법은 중간에 해커가 공개키를 가로챈다 하더라도, 해당 키로는 암호화된 데이터를 복호화하지 못하기 때문에,
키를 주고 받는 과정에서 문제가 되지 않으므로 대칭키보다 보안에 안전합니다.
정리
- 공개키 방법은 공개키를 무한대로 공유해도 개인키가 없으면 데이터를 복호화할 수 없기 때문에 대칭키보다 보안에 안전하다는 장점이 있습니다.
- 반면, 대칭키 방식보다 암호화하는 연산 시간이 더 소요되어 비용이 더 큽니다.
| 대칭키 | 공개키 | |
| 장점 | 암호화 및 복호화 과정이 간편하기 때문에 속도가 빠르고, 비용이 적다. | 암호화는 공개키, 복호화는 개인키를 사용하기 때문에 공개키는 아무에게나 노출이 되어도 상관이 없어, 키를 주고 받는 과정에서 도난의 위험이 없다. |
| 단점 | 암호화와 복호화가 같은 키를 사용하기 때문에, 키를 주고 받을 때 도난의 위험이 있다. |
암호화 및 복호화 과정이 복잡해 비용이 크다. |
따라서, 대칭키의 장점인 속도가 빠르고 비용이 적다는 점이 공개키의 단점이 되고,
대칭키의 단점인 키를 주고 받는 과정에서 보안에 취약하다는 단점이 공개키의 장점이 됩니다.
따라서 SSL에서는 각 방법의 단점때문에 두 방법을 혼합하여 사용하게 되었습니다.
SSL 통신 과정
SSL을 사용하는 주된 목적은 보안입니다.
대칭키와 공개키 방법을 혼합함으로써, 공개키의 장점인 키의 도난 위험이 적어지고, 대칭키의 장점인 비용이 적게 든다는 점을 만족시키는지를 중점으로 보시면 됩니다.
1. A가 B에게 접속을 요청합니다.
2. B는 A에게 공개키를 전송합니다. (공개키는 공개되어도 문제가 없습니다.)
3. A는 전달받은 공개키를 대칭키로 암호화하여, 암호화된 대칭키를 생성합니다.
(생성된 암호화된 대칭키는 공개키로 암호화되었기 때문에, 개인키로 복호화할 수 있습니다.)
4. 암호화된 대칭키를 B에게 전달합니다.
5. B는 개인키로 암호화된 대칭키를 풀어, 원본 대칭키를 얻습니다.
6. 결과적으로, A는 B에게 가지고 있던 대칭키를 도난될 위험없이 전송하게 되었습니다.
또한, 대칭키를 사용해 암호화와 복호화를 진행하므로, 매번 비싼 공개키를 사용해서 암호화와 복호화했던 공개키의 단점이 해소되었습니다.
결론
| 대칭키 | 공개키 | SSL | |
| 장점 | 속도가 빠르고 비용이 적게 든다. | 공개키는 개인키로만 복호화할 수 있기 때문에, 공개키는 도난이 되어도 상관이 없다. | - 대칭키를 공개키로 암호화하여 전달하기 때문에, 키가 도난당해도 복호화가 불가능하여 유출의 위험이 없다. - 공개키는 처음 대칭키를 주고 받을 때만 사용하고, 후에는 대칭키를 사용해 데이터를 암호화 및 복호화를 진행하기 때문에 비용이 적게 든다. |
| 단점 | 키를 주고 받을 때 도난의 위험이 크다. | 암호화 및 복호화하는 과정의 비용이 크다. |
실제 SSL 통신 과정
실제 어떻게 사용자가 접속할 사이트를 신뢰하고, 공개키와 대칭키를 발급받고, 데이터를 주고 받는지
제 3의 인증기관을 포함하여 알아봅시다.
먼저, 사용자가 사이트를 접속하기 전에 사이트는 인증기관에게 신뢰할 수 있는 인증서를 발급받아야 합니다.
[신뢰할 수 있는 사이트 인증서 발급]
- 사이트는 사이트 인증서가 필요합니다.
- 사이트 인증서는 인증기관에서 사이트에게 발급해주는 문서입니다.
- 사이트가 인증기관에게 사이트 정보와 사이트 공개키를 전달합니다.
- 인증기관은 전달받은 데이터를 검증합니다.
- 인증기관에서 검증이 성공적으로 완료되면, 해당 데이터를 자신의 개인키로 서명을 합니다.
- 서명을 하면 사이트 인증서가 생성이 됩니다.
- 생성된 인증서를 사이트에게 전송합니다.
- 인증기관은 인증기관 공개키를 사용자에게 전달합니다. 사이트의 인증서는 인증기관의 개인키로 서명했기 때문에, 해당 인증기관 공개키로 복호화하여 사이트 정보와 사이트 공개키를 얻을 수 있습니다.
- 인증기관으로부터 전달받은 인증기관의 공개키는 브라우저에 자동으로 내장됩니다.
[사용자와 사이트 통신]
1) handshake
사람과 사람이 소통을 할 때 먼저 악수를 하듯, SSL 방식을 이용하여 통신을 하는 브라우저와 서버 역시 악수(handshake)합니다.
1. 사용자는 사이트에게 접속을 요청합니다. (client Hello)
이 단계에서 다음과 같은 정보들을 서버로 전송합니다.
- 클라이언트 측에서 생성한 랜덤 데이터
- 클라이언트가 지원하는 암호화 방식
- 세션 아이디
2. 사이트는 신뢰할 수 있는 사이트임을 증명하기 위해, 사이트 인증서를 전송합니다. (Server Hello)
다음과 같은 정보들을 클라이언트에게 전송합니다.
- 서버 측에서 생성한 랜덤 데이터
- 서버가 선택한 암호화 방식
- 인증서
3. 사용자는 자신이 가지고 있던 인증기관 공개키로 받은 사이트 인증서를 복호화합니다.
사이트 인증서를 해독하면, 사이트 정보와 사이트 공개키를 얻을 수 있습니다.
4. 사용자는 자신의 대칭키를 사이트 공개키로 암호화하여 암호화된 대칭키를 생성합니다.
이때의 대칭키는 주고받은 랜덤 데이터를 조합하여 생성합니다.
5. 암호화된 대칭키를 사이트에게 전달합니다.
6. 사이트는 사이트 개인키로 사용자 대칭키를 복호화하여 사용자 대칭키를 얻습니다.
2) 세션
7. 이제 클라이언트과 서버는 둘 다 대칭키를 가지고 있게 됩니다. 대칭키를 사용하여 데이터를 암호화 및 복화하여 데이터를 주고 받습니다.
3) 종료
데이터 전송이 끝나면 SSL 통신이 끝났음을 서로에게 알려주고 세션키는 폐기합니다.
결과
- SSL은 사이트 외에 인증기관과 협력하기 때문에 안전한 접속방법이 됩니다.
따라서, 사용자가 접속하는 사이트가 믿을 수 있는 사이트인지 확인이 가능합니다. - 공개키와 대칭키를 혼합한 방식을 사용하여, 안전하고 비용이 적은 데이터 전송이 가능하게 되었습니다.
SSL을 무료로 발급해주는 인증 기관
참고) 인증서 발급기관과 내용
1) CA
- 인증서를 발급해주는 인증기관을 CA(Certificate Authority) 혹은 Root Certificate라고 합니다.
- CA는 어떤 사이트가 신뢰할 수 있는 사이트인지 보장하는 역할을 합니다.
- 따라서, SSL을 통해서 암호화된 통신을 제공하려는 서비스는 CA를 통해서 인증서를 구입해야 합니다.
- chrome, safari 등 각각의 브라우저에는 공인된 CA 리스트와 각 CA의 공개키가 탑재되어 있습니다.
- 만약 직접 사용하는 개발 서버나 사내 서버의 경우, 이미 사이트의 신뢰가 확보되어 있기 때문에 굳이 인증서를 사용하지 않아도 됩니다.
- 하지만 만약 SSL의 암호화 기능을 이용하려 한다면, 직접 자신이 CA의 역할을 할 수 있습니다.
- 물론, 이것은 공인된 인증서가 아니기 떄문에 사적인 서비스가 아니라 공개된 서비스에 사용한다면 아래와 같은 경고를 출력하게 됩니다.
- 아래 사진은 이 사이트는 SSL 서비스를 제공하고 있긴 하지만, 이 사이트가 공인된 기관에 의해서 보증된 사이트가 아니라는 뜻입니다.
- 반면, 공인된 CA가 제공하는 인증서를 사용한다면 아래와 같이 나타납니다.
2) 인증서의 내용
인증서는 다음과 같은 내용을 담고 있습니다.
- 서비스 정보 (인증서를 발급한 CA, 서비스의 도메인 등)
- 서버 측 공개키 (공개키의 내용, 공개키의 암호화 방법)
서비스 정보는 클라이언트가 접속한 서버가 클라이언트가 의도한 서버가 맞는지에 대한 내용을 담고 있습니다.
참고) 전자서명
인증기관이 자신의 개인키로 서명을 하는 방식이 전자서명 방식이라는 것을 알게 되어 추가로 공부하게 되었습니다.
예로부터 사람들은 거래 또는 약속의 이행을 위해 개인을 증명할 수 있는 표식을 해왔습니다.
컴퓨팅 시대에 접어들어 이러한 표식을 디지털에서도 구현을 했는데, 이것을 디지털 서명 또는 전자서명이라고 합니다..
즉, 전자서명은 디지털 시스템을 통해 문서나 데이터의 무결성을 보장하기 위해 사용되는 기술입니다.
전자서명 동작 원리
활용 예시
- 전자 문서 및 계약 : 전자서명은 온라인 문서, 계약, 합의서 등을 디지털 서명으로 보호하는데 사용됩니다. 전자문서를 통해 문서의 무결성과 소유자의 인증이 보장되므로 문서가 변조되지 않았음을 인증하고, 서명한 당사자를 확인할 수 있습니다.
- 온라인 거래 : 인터넷 상에서 주문서, 결제서, 온라인 계약 등의 거래에 사용됩니다. 전자서명은 거래의 신뢰성과 안전성을 보장하여 사기나 부정한 행위로부터 보호합니다.
- 인증 및 접근 제어 : 전자서명은 인증 시스템에 활용되어 사용자의 신분을 확인하고, 데이터에 접근 제어를 적용합니다. 보안 강화를 위해 암호화와 결합하여 사용자의 개인정보와 중요한 데이터를 보호하는 데 사용됩니다.
- 전자문서 보관 : 디지털 서명을 사용하여 전자 문서를 무결성과 보안을 유지하며 안전하게 보관할 수 있습니다. 기업이나 기관은 전자 문서의 오랜 기간 보관을 위해 전자서명을 활용합니다.
- 정부 및 법률 분야 : 정부 기관이나 법률 분야에서 전자서명은 각종 양식, 신고, 신청서 등의 제출에 사용됩니다. 이를 통해 프로세스가 디지털화되고 효율성이 증가됩니다.
- 의료 기록 및 계약 : 의료 분야에서 환자 기록이나 의료 계약을 전자서명으로 보호하고, 인증과 보안을 유지하는 데 사용됩니다.
전자서명의 5가지 필수 원칙
- 위조 불가 조건 : 합법적인 서명자만이 전자문서에 대한 전자서명을 생성할 수 있다.
- 서명자 인증 조건 : 전자 서명의 서명자를 누구든지 검증할 수 있다.
- 부인 불가 조건 : 서명자는 서명 후에 자신의 서명 사실을 부인할 수 없다.
- 변경 불가 조건 : 서명한 문서의 내용은 변경할 수 없다.
- 재사용 불가 조건 : 전자문서의 서명은 다른 전자문서의 서명으로 사용될 수 없다.
위의 5가지 원칙을 준수하지 않았을 때는 전자서명의 가치를 가지기가 어렵습니다.
참고
- https://www.youtube.com/watch?v=wPdH7lJ8jf0
- chat gpt
- https://beaniejoy.tistory.com/30
- https://m.blog.naver.com/jvioonpe/221384924295
- https://study-recording.tistory.com/11
'CS > 네트워크' 카테고리의 다른 글
| [HTTP] HTTP Header 4 (프록시 캐시) (0) | 2023.05.09 |
|---|---|
| [HTTP] HTTP Header3 (캐시) (0) | 2023.05.07 |
| [HTTP] HTTP Header2 (전송 방식, 일반, 특별, 인증(쿠키)) (0) | 2023.05.03 |
| [HTTP] HTTP Header1 (표현 Header, 협상 ) (0) | 2023.05.02 |
| [HTTP] HTTP 상태 코드 (0) | 2023.04.20 |
