| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | ||||
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | 31 |
Tags
- ResourceQuota
- 빅데이터
- k8s
- 혼잡제어
- cronjob
- 웹 스토리지
- OverTheWire
- 해커톤
- dns
- daemonset
- 리소스 풀링
- 핸드셰이크
- 온프레미스
- 클라우드
- 클라우드 네이티브 5회차
- Web
- 네트워크 가상화
- Urn
- 해시
- LimitRange
- docker
- 네트워크
- 도커
- Replicaset
- 고가용성
- 하둡
- goorm
- configmap
- namespace
- 다중화
Archives
- Today
- Total
NakedFlower 님의 블로그
네트워크 인증 본문
지난 시간에는 '안정성'을 위한 기술을 다루었다 이번 시간에는 '안전성'을 위한 기술을 다루도록 하겠다
안전한 네트워크를 위한 기술에는
- 암호화 & 복호화 -> 암호화 : 원본 데이터를 알아보기 어려운 형태로 변경하는 과정 -> 복호화 : 암호화된 데이터를 원본 데이터로 되돌리는 과정 -> 안전한 데이터 송수신 뿐만 아니라 인증서 기반의 검증도 가능하게 함
암호화와 복호화의 핵심은 '키' 키에 수학적 연산(= 암호화 알고리즘)을 거치면 암호문 생성
- 키를 기반으로 암호화/복호화하는 두가지 방식
- 대칭키 암호화
- 공개키 암호화
- 대칭키 암호화
- 암호화와 복호화에 동일한 키를 사용하는 방식
- 동일한 키를 사용하므로 키가 유출되면 큰 문제 발생
- 따라서 당연하게도 키를 안전하게 상대방에 전달해야 함
- 공개키 암호화(비대칭키 암호화)
- 암호화와 복호화에 사용되는 키가 다름
- 한쌍의 키(공개키, 개인키)를 사용; 한 키로 암호화, 다른 키로 복호화
- 공개키를 알아도 개인키 유추 불가능, 역도 마찬가지
- 대칭키 암호화 방식
- 장점 : 적은 부하, 빠른 암호화 및 복호화 수행 가능
- 단점 : 키를 안전하게 전송하기 어려움
- 공개키 암호화 방식
- 장점 : 안전한 키 공유 가능
- 단점 : 높은 부하, 암호화 및 복호화 느림

대칭 키를 공개키로 암호화하고 개인 키로 암호화된 대칭 키를 복호화한다면?
-> 안전한 대칭키 공유 가능
-> 빠른 대칭키 기반 암복호화 가능
-> 이렇게 활용되는 대칭키 = 세션키
인증서와 디지털 서명
- 인증서(certificate)
- 무엇인가를 증명하기 위한 문서
- 네트워크(인터넷)에서의 인증서 = 일반적으로 '공개 키 인증서(public key certificate)'
인증서와 디지털 서명
- 공개 키 인증서(public key certificate)
- 공개 키와 공개 키의 유효성을 입증하기 위한 전자 문서
- 인증 기관(CA, Certification Authority)
- 인증서의 발급, 검증, 저장과 같은 역할을 수행할 수 있는 공인 기관
- 대표적인 인증 기관
- IdenTrust
- DigiCert
- GlobalSign 등
- 서명 값(signature)
- 인증 기관(CA)의 인증 정보
- "이 공개 키 인증서는 진짜야, 내가 보증할게"
- 클라이언트는 CA가 발급한 인증서의 서명 값을 바탕으로 인증서를 검증

서명 값 생성의 원리
- 인증서 내용에 대한 해시 값을
- CA의 개인 키로 암호화하는 방식으로 생성
- CA는 이렇게 얻어낸 정보를 서명 값으로 삼아 클라이언트에게 인증서와 함께 전송

공개키로 복호화를 할 수 있다 -> CA의 개인 키로 암호화를 했구나! 라는 것을 의미함
해시 값?
- 해시 함수를 적용시킨 결과값
- 해시 함수
- 임의의 길이의 데이터를 고정된 길이의 데이터로 변환하는 함수
- MD5, SHA-1, SHA-2(SHA-256, SHA-384, SHA-512) 등
- 입력값에 민감: 입력 데이터가 조금만 달라져도 완전히 다른 결과가 나옴
- 데이터 변조 여부 검사에 사용
- '보낼 데이터' + '데이터에 대한 해시 값'을 함께 전송
- 수신자가 전달받은 데이터에 대한 해시 값을 직접 계산
- 계산 결과를 전달받은 해시 값과 비교
- 같은 값이 도출된다면? 데이터 전송 도중 변조되거나 소실되지 않았다고 판단
인증서 검증 과정
1. 서명값과 인증서 분리
2. 전달받은 서명 값을 CA의 공개키로 복호화하여 해시값을 얻음
3. 인증서 데이터에 대한 해시값을 직접 계산
4. 이를 2번에서 복호화한 값과 비교
디지털 서명(digital signature)
- 개인 키로 암호화된 메시지를 공개 키로 복호화함으로써 신원을 증명하는 절차
HTTPS: SSL과 TLS
- SSL(Secure Sockets Layer)과 TLS(Transport Layer Security)
- 인증과 암호화를 수행하는 프로토콜
- TLS는 SSL을 계승한 프로토콜. 작동 과정은 큰 틀에서 보면 유사함
- 초기 SSL 2.0과 SSL 3.0을 거쳐 TLS 1.0, TLS 1.1, TLS 1.2, TLS 1.3이 순차적으로 출시 (오늘날 자주 사용되는 버전 (여기선 TLS 1.3 기준으로 설명))
- HTTPS(HTTP over TLS)
- SSL/TLS를 사용하는 대표적인 프로토콜
- HTTPS는 HTTP 메시지의 안전한 송수신을 위해 개발된 프로토콜

HTTPS 메시지의 송수신 단계
1. TCP 쓰리 웨이 핸드셰이크
2. TLS 핸드셰이크(인증서와 키를 주고받음)
- 암호화 통신을 위한 키 교환 / 인증서 송수신과 검증이 이루어지는 단계
3. 암호화된 메시지 송수신

- TLS 핸드셰이크에서의 키 교환
- 클라이언트의 ClientHello 메시지
- 암호화된 통신을 위해 서로 맞춰 봐야 할 정보들을 제시하는 메시지
- 선택 가능한 TLS 버전, 사용 가능한 암호화 알고리즘과 해시 함수, 키 생성에 필요한 난수 등이 포함
- 서버의 ServerHello 메시지
- ServerHello 메시지는 제시된 정보들을 선택하는 메시지
- 선택된 TLS 버전, 사용 가능한 암호화 알고리즘과 해시 함수, 키 생성에 필요한 난수 등이 포함
- ClientHello, ServerHello를 주고받으면 암호화 통신을 위해 사전 합의해야 할 정보들이 결정됨
- 서버와 클라이언트는 암호화에 사용할 키를 생성
- 클라이언트의 ClientHello 메시지
- TLS 핸드셰이크에서의 인증서 및 인증서 검증
- 서버는 Certificate 메시지와 CertificateVerify 메시지 전송
- 각각 인증서와 검증을 위한 디지털 서명
- 클라이언트는 이 메시지를 토대로 서버의 공개 키 검증
- 서버는 Certificate 메시지와 CertificateVerify 메시지 전송
- TLS 핸드셰이크 마무리, 암호화 통신 수행
- 서버와 클라이언트는 TLS 핸드셰이크의 마지막을 의미하는 Finished 메시지를 주고 받음
- 이때 주고받은 키를 바탕으로 암호화 데이터(Application Data) 주고받음
'CS > 네트워크' 카테고리의 다른 글
| 무선 네트워크 (0) | 2025.10.04 |
|---|---|
| 고가용성, 이중화, 다중화, 로드밸런싱 (1) | 2025.10.04 |
| HTTP 기반 기술 (1) | 2025.10.04 |
| HTTP에 대하여 (0) | 2025.10.04 |
| Domain Name Server (0) | 2025.10.03 |