해당 글은 VSFe 깃허브 레포를 참고하여 작성한 글입니다. (아래 출처에 표기)
✅ HTTP에 대해 설명해 주세요.
HTTP(HyperText Transfer Protocol)이란 텍스트 기반의 통신 규약으로서 클라이언트와 서버 간에 데이터를 주고받기 위한 통신 프로토콜이다. HTTP는 요청-응답(request-response) 모델을 기반으로 하며, 이 모델을 통해 클라이언트가 서버에 요청(request)을 보내고, 서버가 클라이언트에 응답(response)을 반환한다.
▶ HTTP의 특징
- 클라이언트-서버 모델
- 클라이언트와 서버가 명확하게 구분된다. 클라이언트는 요청(request)를 보내고, 서버는 요청을 처리하여 응답(response)을 반환한다.
- TCP/IP 기반
- HTTP는 TCP/IP를 이용하는 응용 프로토콜이다. TCP/IP는 인터넷이라는 거대한 통신망을 통해 컴퓨터 간에 데이터를 전송할 수 있도록 하는 프로토콜 스택이다.
TCP/IP와 관련된 자세한 설명은 여기를 참고하면 좋을 것 같다.
- 무상태(Stateless)
- HTTP는 무상태(Stateless) 프로토콜이다. 각 요청은 독립적으로 처리되며, 이전 요청의 정보를 저장하지 않는다. Stateless의 단점을 보완하기 위해 쿠키와 세션이 사용된다.
무상태(Stateless)와 관련된 자세한 설명은 여기와 여기를 참고하면 좋을 것 같다.
- 비연결성(Connectionless)
- HTTP는 연결 상태를 유지하지 않는 비연결성(Connectionless) 프로토콜이다. 요청을 보내고 응답을 받으면 연결이 끊어진다.
비연결성(Connectionless)과 관련된 자세한 설명은 여기를 참고하면 좋을 것 같다.
- HTTP Method
- HTTP는 다양한 작업을 수행하기 위해 여러 가지 메서드를 사용한다. 주요 메서드로는 GET, POST, PUT, DELETE, PATCH 등이 있다.
HTTP Method와 관련된 자세한 설명은 여기를 참고하면 좋을 것 같다.
- 상태 코드
- HTTP 응답에는 상태 코드가 포함되어 있어, 요청이 성공적으로 처리되었는지, 오류가 발생했는지 등을 나타낸다.
상태 코드와 관련된 자세한 설명은 여기를 참고하면 좋을 것 같다.
- 헤더(Headers)
- HTTP 요청과 응답은 헤더를 포함하여 메타데이터를 전송한다. 헤더에는 콘텐트 타입, 인코딩, 쿠키, 캐시 제어 등 다양한 정보가 포함될 수 있다.
▶ HTTP의 동작 방식
- 클라이언트가 요청을 생성
- 클라이언트는 URL을 입력하거나 링크를 클릭하여 서버에 요청을 생성한다.
- 서버가 요청을 처리
- 서버는 요청을 받아 해당 리소스를 찾고, 응답을 생성한다.
- 응답 반환
- 서버는 요청에 대한 응답을 클라이언트에 반환한다. 응답 상태에는 상태 코드, 헤더, 본문(필요한 경우)이 포함된다.
- 클라이언트가 응답을 처리
- 클라이언트는 서버의 응답을 받아서 화면에 표시하는 등의 추가 작업을 수행한다.
▶ Request HTTP 메시지 예시
POST /submit-form HTTP/1.1 //요청 라인(Request Line)
Host: www.example.com //헤더(Header)
Content-Type: application/x-www-form-urlencoded
Content-Length: 27
username=johndoe&password=1234 //본문(Body)- 요청 라인(Request Line): 메서드(GET, POST 등), 요청 대상(경로), HTTP 버전으로 구성된다.
- 헤더(Header): 요청에 대한 정보를 제공하는 키-값 쌍이다. Host, User-Agent, Accept 등이 있다.
- 본문(Body): POST 요청 등에서 사용되며, 전송할 데이터를 포함한다.
▶ Response HTTP 메시지 예시
HTTP/1.1 200 OK //상태 라인(Status Line)
Date: Sat, 26 Jul 2024 12:28:53 GMT //헤더(Header)
Server: Apache/2.4.41 (Ubuntu)
Last-Modified: Wed, 22 Jul 2024 19:15:56 GMT
ETag: "5d8c72a5c58e8"
Accept-Ranges: bytes
Content-Length: 396
Content-Type: text/html
<!DOCTYPE html><html><head><title ... //본문(Body)- 상태 라인(Status Line): HTTP 버전, 상태 코드(200, 404 등), 상태 메시지로 구성된다.
- 헤더(Header): 응답에 대한 정보를 제공하는 키-값 쌍이다. Date, Server, Content-Type 등이 있다.
- 본문(Body): 응답 내용이 포함된다. HTML 페이지, JSON 데이터 등이 있다.
✅ 대칭키와 공개키에 대해 설명해 주세요.
대칭키 암호화(Symmetric Key Encryption)와 공개키 암호화(Public Key Encryption)는 두 가지 주요 암호화 방식이다.
- 대칭키 암호화: 암호화와 복호화에 사용하는 키가 동일하다.
- 공개키 암호화: 암호화와 복호화에 사용하는 키가 서로 다르다. 비대칭키 암호화라고도 불린다.
▶ 대칭키와 공개키의 과정
❗️ 아래의 내용들을 이해하기 위해서는 각각의 암호화 과정에 대해서 정확하게 짚고 넘어가야 해서 먼저 설명한다.
🔽 대칭키 암호화 과정
- 단일 키 교환
- 데이터를 전송하기 전, 먼저 송신자와 수신자가 동일한 단일 키를 안전한 방법으로 교환한다.
- 암호화 과정
- 송신자는 데이터를 암호화할 때 단일 키인 대칭키를 사용한다.
- 데이터 전송
- 암호화된 데이터는 수신자에게 전달된다.
- 복호화 과정
- 수신자는 동일한 대칭키를 사용하여 암호화된 데이터를 복호화한다.
- 대칭키를 알고 있는 수신자만이 원본 데이터를 복원할 수 있다.
🔽 공개키 암호화 과정
- 키 쌍 생성
- 데이터를 전송하기 전, 각 사용자는 자신만의 공개키와 비공개키 쌍을 생성한다.
- 비공개키: 각 사용자만 알고 있는 비밀 키이다.
- 공개키: 공개적으로 배포가 가능한 키이다.
- 데이터를 전송하기 전, 각 사용자는 자신만의 공개키와 비공개키 쌍을 생성한다.
- 공개키 배포
- 생성된 공개키를 공개적으로 배포한다. (예: 웹사이트 게시, 인증 기관을 통해 배포 등)
- 암호화 과정
- 송신자는 수신자의 공개키를 사용하여 데이터를 암호화한다.
- 공개키는 암호화 알고리즘의 매개변수로 사용된다. (특정 암호화 알고리즘의 예시를 보면 이해가 쉽다.)
- 송신자는 수신자의 공개키를 사용하여 데이터를 암호화한다.
- 데이터 전송
- 암호화된 데이터는 수신자에게 전달된다.
- 복호화 과정
- 수신자는 자신의 비공개키를 사용하여 암호화된 데이터를 복호화한다.
- 비공개키는 수신자만 알고 있으므로, 복호화된 데이터는 오직 수신자만이 확인할 수 있다.
▶ 대칭키
- 양방향 암호화 방식 중 널리 사용하는 대칭키 암호화 방식은 암호화, 복호화에 같은 암호 키를 사용하는 알고리즘이다.
🔽 특징
- 장점
- 간단한 구조: 구현이 비교적 간단하고, 계산 비용이 적다.
- 속도: 데이터를 암호화하기 위한 연산이 빠르고 효율적이어서 대용량 데이터 암호화에 적합하다.
- 기밀성 제공: 데이터를 대칭키로 암호화, 동일한 키로 데이터를 복호화한다.
- 단점
- 키 분배 문제: 동일한 키를 암호화와 복호화에 사용하므로 이 키를 통신하는 양쪽이 모두 알아야 한다. 따라서 키를 안전하게 공유하고 교환하는 것이 비교적 어렵다.
- 키 탈취 문제: 키가 탈취될 위험이 있으며, 이를 방지하기 위해 키를 주기적으로 교체해야 한다.
- 확장성 부족: 사용자 수가 증가하면, 각 사용자 쌍마다 별도의 키를 사용해야 하므로 키 관리가 어렵다.
- 무결성 및 부인 방지 제공하지 않음: 무결성 지원이 부분적으로만 가능하며, 부인 방지 기능을 제공하지 못한다.
- 대표적인 알고리즘
- SEED: 한국의 정보 보호 표준, 128비트 키 사용
- AES: 미국 NIST에서 제정한 블록 암호 표준, 강력한 보안성을 제공
- DES:블록 암호 알고리즘, 56비트 키를 사용, 키 길이가 짧아 보안성이 부족
- 3DES: DES의 보안을 강화하기 위해 개발된 알고리즘, DES 알고리즘을 세 번 반복하여 사용하는 방식
▶ 공개키(비대칭키)
- 공개키는 암호화할 때와 복호화할 때의 키를 서로 다른 키로 사용하는 알고리즘이다. 외부로 절대 노출되어서는 안 되는 비공개키(개인키)(Private Key)와 공개적으로 개방되어 있는 공개키(Public Key)가 쌍으로 이루어진 형태이다.
🔽 특징
- 장점
- 키 분배 용이: 공개키는 자유롭게 배포할 수 있고, 비공개키는 소유자만 알고 있으면 되기 때문에 키 관리가 비교적 용이하다.
- 보안성: 단일 키를 사용하는 대칭키 암호화 방식과는 달리, 공개키가 유출되더라도 비공개키가 유출되지 않으면 데이터를 안전하게 보관할 수 있다.
- 무결성 및 부인 방지 제공: 디지털 서명을 통해 데이터의 무결성과 부인 방지 기능을 제공한다.
- 기밀성 제공: 누구나 접근 가능한 공개키를 통해 데이터 암호화, 소유자만 알고 있는 비공개키로 암호화된 데이터를 복호화한다.
- 단점
- 복잡한 구조: 수학적으로 더 복잡하며, 구현이 어렵고 계산 비용이 높다.
- 속도: 비교적 느리다. 큰 데이터를 처리하는 데 비효율적이다.
- 대표적인 알고리즘
- Diffle-Hellman: 최초의 공개키 알고리즘, 위조에 취약
- RSA: 대표적 공개키 알고리즘, 1024비트 이상의 키를 사용
- DSA: 전자 서명 알고리즘 표준, 해시 함수와 함께 사용
- ECC: 짧은 키로도 높은 보안성, 빠른 구현 가능, PDA 및 스마트폰 등에 사용
▶ 대칭키와 공개키의 기밀성, 무결성, 부인 방지
🔽 기밀성(Confidentiality)
허가되지 않은 사용자에게 노출되지 않도록 보호하는 원칙, 데이터의 비밀 유지 및 무단 접근과 노출을 방지한다.
- 대칭키: 암호화와 복호화에 동일한 키를 사용한다. 송신자와 수신자는 동일한 대칭키로 데이터를 암호화, 복호화한다. 이 키가 유출되지 않는 한 기밀성이 유지된다.
- 공개키: 공개키와 비공개키 쌍을 사용한다. 송신자는 수신자의 공개키로 암호화하고, 수신자는 자신의 비공개키로 복호화한다. 공개키가 유출되더라도 비공개키가 유출되지 않으면 기밀성이 유지된다.
🔽 무결성(Integrity)
데이터가 전송 중이나 저장 중에 변조되지 않고 원래의 상태를 유지하도록 보장하는 원칙, 데이터의 정확성과 신뢰성을 보장한다.
- 대칭키: 데이터의 무결성을 보장하는 기능이 없다. 추가적인 메커니즘이 필요하다.
- 공개키: 디지털 서명을 사용하여 무결성을 보장한다. 송신자가 비공개키로 데이터를 서명하고, 수신자는 송신자의 공개키로 서명을 검증한다. (데이터에 해시 값을 적용하고 서명하여 데이터가 변조되지 않았음을 보장한다.)
🔽 부인 방지(Non-Repudiation)
데이터의 송신자가 데이터를 송신한 사실을 부인할 수 없도록 하는 원칙, 특정 행동이나 거래가 실제로 발생했음을 증명할 수 있는 기능, 거래의 신뢰성을 보장한다.
- 대칭키: 부인 방지를 보장하는 기능이 없다. 추가적인 메커니즘이 필요하다.
- 공개키: 부인 방지를 직접 지원한다. 송신자가 자신의 비공개키로 데이터를 서명하면, 서명된 데이터와 서명 자체는 송신자의 공개키로 검증할 수 있다. (디지털 서명을 사용하여 송신자가 데이터를 송신한 사실을 증명한다.)
(공개키) 서명은 암호화와 별도로 처리된다.
1. 송신자는 서명 데이터를 해시하여 해시값을 생성하고, 이 해시값을 송신자의 비공개키로 암호화하여 서명을 만든다.
2. 송신자는 서명과 함께 원본 데이터를 수신자에게 전송한다.
3. 수신자는 송신자의 공개키를 사용하여 서명을 복호화하여 해시값을 추출한 후 원본 데이터로부터 새로운 해시값을 생성하고, 추출한 해시값을 비교한다.
✅ SSL과 TLS의 차이는 무엇인가요?
▶ SSL/TLS Handshake
클라이언트와 서버 간의 안전한 통신을 설정하기 위해 SSL/TLS 프로토콜을 사용하여 수행되는 초기화 과정이다.
🔽 과정
- Client Hello
- 클라이언트가 서버에 연결을 시도하며 "Client Hello" 메시지를 전송한다.
- 이 메시지에는 클라이언트가 지원하는 암호화 알고리즘, SSL/TLS 버전, 세션 ID, 랜덤 데이터(서버와의 통신을 위한 무작위 숫자) 등이 포함된다.
- Server Hello
- 서버는 클라이언트의 요청에 대한 응답으로 "Server Hello" 메시지를 전송한다.
- 이 메시지에는 암호화 알고리즘, SSL/TLS 버전, 서버가 선택한 세션 ID, 서버 랜덤 데이터 등이 포함된다.
- Certificate (서버 인증)
- 서버는 자신의 SSL 인증서를 클라이언트에 전달한다. 이 인증서에는 서버의 발행한 공개키가 들어있다.
- 클라이언트는 서버가 보낸 CA(Certificate Authority, 인증기관)의 개인키로 암호화된 이 SSL 인증서를 이미 모두에게 공개된 CA의 공개키를 사용하여 복호화한다. 복호화에 성공하면 이 인증서는 CA가 서명한 것임으로 인증서 검증에 성공한다.
- Server Key Exchange (서버 키 교환)
- 서버의 공개키가 SSL 인증서 내부에 없는 경우, 서버가 직접 전달함을 의미한다. 공개키가 SSL 인증서 내부에 있을 경우 Server Key Exchange는 생략된다.
- 인증서 내부에 공개 키가 있다면 클라이언트가 CA의 공개키를 통해 인증서를 복호화한 후 서버의 공개키를 확보할 수 있다.
- Client Key Exchange (클라이언트 키 교환)
- 클라이언트는 Server Key Exchange에서 추출한 서버의 공개키를 이용하여 대칭키를 암호화한 후 서버에 전달한다.
- 이 대칭키가 SSL Handshake의 목적이자 가장 중요한 수단인 데이터를 실제로 암호화할 대칭키이다.
- Server Finished (서버 인증 완료)
- 서버는 클라이언트로부터 세션 키를 수신한 후, "Finished" 메시지를 보낸다.
- 이 메시지는 현재까지의 Handshake 과정이 무결하게 수행되었음을 확인하는 내용이 포함되어 있다.
- Client Finished (클라이언트 인증 완료)
- 클라이언트는 "Finished" 메시지를 서버에 보낸다.
- 이 메시지 역시 Handshake 과정의 무결성을 확인하는 데 사용된다.
- 이제 클라이언트와 서버는 세션 키를 사용하여 암호화된 통신을 시작할 준비가 된다.
악수(Client Hello, Server Hello) ➡️ 서버가 클라이언트에게 자신을 인증(Certificate) ➡️ 서버의 공개키를 통해 클라이언트가 대칭키 생성 및 교환(Server Key Exchange, Client Key Exchange) ➡️ 인증 완료(Server Finished, Client Finished)
▶ SSL과 TLS의 차이점
SSL과 TLS은 HTTPS 통신에 사용되는 암호화 프로토콜이다.
- SSL (Secure Sockets Layer): SSL은 TLS의 이전 버전으로, 현재는 보안 취약점으로 인해 사용이 권장되지 않는다.
- 보안: 여러 보안 취약점이 발견되어 보안성이 낮다.
- Handshake 및 성능: Handshake 과정이 비효율적이며, 성능 최적화가 부족하다.
- 버전 호환성: 최신 웹 브라우저와 서버에서 지원되지 않거나 비활성화되는 경우가 많다.
- TLS (Transport Layer Security): TLS는 SSL의 후속 프로토콜로, 보안성을 향상시키고 최신 암호화 알고리즘을 지원한다.
- 보안: SSL에서 발견된 취약점을 수정하고, 암호화 알고리즘과 해시 함수를 개선하여 보안성을 높였다.
- Handshake 및 성능: Handshake 과정이 개선되어 성능이 향상되었다. 속도가 빨라지고, 보안성이 강화되었다.
- 버전 호환성: 최신 웹 브라우저와 서버에서 널리 사용된다.
✅ 왜 HTTPS Handshake 과정에서는 인증서를 사용하는 것일까요?
- 인증: 인증서를 통해 서버의 신원을 확인함으로써, 클라이언트는 자신이 연결하려는 서버가 실제로 신뢰할 수 있는 서버인지 확인할 수 있다.
- 암호화: 인증서에 포함된 공개키를 사용하여 대칭키를 안전하게 교환함으로써, 클라이언트와 서버 간의 데이터 전송을 암호화할 수 있다.
- 무결성: 인증서와 Handshake 과정에서 전송되는 데이터의 무결성을 검증함으로써, 데이터가 변조되지 않았음을 확인할 수 있다.
- 신뢰성: 공인된 CA가 서명한 인증서를 통해 클라이언트는 서버의 신뢰성을 검증할 수 있다.
📍 문제 출처
Tech-Interview / 03-NETWORK.md
📍 참고 자료
'Programming > Network' 카테고리의 다른 글
| [Network] HTTP/1.1, HTTP/2.0, HTTP/3.0 (0) | 2024.07.28 |
|---|---|
| [Network] 소켓, 웹소켓, 포트 (0) | 2024.07.28 |
| [Network] HTTP Method (0) | 2024.07.23 |
| [Network] HTTP 응답 코드 (0) | 2024.07.19 |
| [Network] 쿠키와 세션 (0) | 2024.07.19 |
