4. HTTP에 대해 설명해 주세요.

[KIMSEI1124]

• 공개키와 대칭키에 대해 설명해 주세요.
• 왜 HTTPS Handshake 과정에서는 인증서를 사용하는 것 일까요?
• SSL과 TLS의 차이는 무엇인가요?

[KIMSEI1124]

참고 자료 : Mozilla - HTTP

HTTP란?
하이퍼텍스트 전송 프로토콜은 HTML과 같은 하이퍼미디어 문서를 전송하기 위한 Application Layer 프로토콜입니다.
웹 브라우저와 웹 서버간의 통신을 위해 설계되었지만 다른 목적으로도 사용할 수 있습니다.

HTTP는 클라이언트가 요청하기 위해 연결을 연 다음 응답을 받을때 까지 대기하는 전통적인 클라이언트-서버 모델을 따르며 무상태 프로토콜이며, 서버가 두 요청 간에 어떠한 데이터(상태)도 유지하지 않습니다.

핵심 요소

HTTP는 기본적으로 요청/응답 구조로 되어있다.

통신 방식

클라이언트가 HTTP Requset를 서버에 보내면 서버는 HTTP Response를 보내는 구조이며, 모든 통신이 요청과 응답으로 이뤄진다.
HTTP는 Stateless이며, 요청이 오면 그에 응답할 뿐, 여러 요청/응답 끼리 연결되어 있지 않다.

구조

HTTP Request 메시지는 크게 3부분으로 구성된다.

• Start Line
• Headers
• Body

아래는 HTTP Request 메시지입니다.

POST /idempotence HTTP/1.1
Accept: application/json, */*;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Content-Length: 15
Content-Type: application/json
Host: localhost:8080
User-Agent: HTTPie/3.2.3
{
    "name": "KIM"
}

1. Start Line
   1. HTTP Method
      의도한 행동을 정의하는 부분이며 GET, POST, PUT과 같은 HTTP Method등이 있습니다.
   2. Request Target
      해당 Request가 전송되는 목표 URI입니다.
   3. HTTP Version
      사용되는 HTTP 버젼입니다.
2. Headers
   해당 Request에 대한 추가 정보를 담고 있는 부분이며 Key-Value로 이뤄집니다.
   1. Accept
      해당 요청이 받을 수 있는 응답 타입
   2. Connection
      해당 요청이 끝난후에 클라이언트와 서버가 계속해서 네트워크 커넥션을 유지 할것인지 아니면 끊을 것인지에 대한 지시하는 부분
   3. Content-Length
      해당 요청이 보내는 메시지의 길이
   4. Content-Type
      해당 요청이 보내는 메시지 Body의 타입
   5. Host
      요청이 전송되는 대상의 HOST URL
   6. User-Agent
      요청을 보내는 클라이언트의 대한 정보
3. Body
   해당 Request의 메시지/내용

아래는 Request에 대한 HTTP Response 메시지입니다.

HTTP/1.1 201
Connection: keep-alive
Content-Type: application/json
Date: Wed, 17 Jul 2024 11:40:07 GMT
Keep-Alive: timeout=60
Transfer-Encoding: chunked
{
    "id": 1,
    "name": "KIM"
}

Response에서는 Request와 다르게 Start Line에서 HTTP Method, Request Target대신 Http Status Code를 전송합니다.

연결 종류

HTTP는 어떻게 연결하느냐에 따라서 다음과 같이 분류할 수 있습니다.

1. Non-Persistent HTTP
   HTTP의 초기 모델로, 한번의 연결에 1개의 컨텐츠를 처리하는 형식입니다.
2. Persistent HTTP
   한 번 연결하는 동안에 컨텐츠를 계속해서 교환하는 형식입니다. TCP로 처음 연결하는데 RTT(Round Trip Time)이 너무 오래 걸려서 고안된 연결 방식입니다.
   참고로 RTT는 패킷을 전송하고 다시 되돌아올 때 걸리는 Queueing Delay와 Propagation Delay를 고려한 시간을 나타냅니다.
3. HTTP Pipelining
   한 번 연결하는 동안에 컨텐츠를 계속해서 교환하되, pipelining을 통해 더 효율적으로 컨턴츠를 교환할 수 있는 방법입니다.

4.1. 공개키와 대칭키에 대해 설명해 주세요.

참고 자료: [Network] HTTPS 암호화에 대하여(대칭키, 공개키)

암호화란?

암호화는 암호화 알고리즘과 암호화 키를 이용해서 데이터를 남들이 해석할 수 없도록 만드는 것
암호화 알고리즘은 공개되어 있으며, 암호화에서 사용되는 키를 어떻게 생성하고 관리하느냐가 핵심

대칭키 ( Symmetric Key ) 방식

암호화 키와 복호화 키가 같은 방식

키를 보내지 않으면 복호화를 할 수 없고, 키를 보내면 도중에 탈취될 가능성이 있는데 이를 키 배송 문제(key distribution problem)라고 한다.

이와 같이 중간에서 탈취될 가능성이 존재하기 때문에 공개키 방식이 나오게 되었습니다.

공개키 ( Public Key ) 방식

공개키, 개인키가 하나의 묶음으로 동작한다.
즉, 공개키로 암호화를 하면 개인키로만 복호화할 수 있고, 개인키로 암호화하면 공개키로만 복호화할 수 있다.

공캐키 암호화
공캐키를 암호화하고, 복호화는 개인키로만 가능한 방법이다. 복호화가 개인키로만 가능하기 때문에, 데이터가 보호되어야 할 때 사용한다.

전자 서명
개인키를 암호화는 방식이다. 따라서 공개키로 복호화가 가능하다. 즉, 나의 개인키에 대한 공개키를 알고 있는 사람이라면 누구나 복호화할 수 있다. 당연히 보안이 중요한 데이터는 이 방법으로 암호화하면 안된다. 대신 이 데이터를 보낸 사람이 **나라는 것을 증명(인증)**할 수 있다. 공개키와 개인키는 쌍으로 동작하기 때문에, 특정 공개키로 복호화 가능하다는 것은 해당 공개키의 쌍인 개인키로 암호화된었다는 것을 의미한다. 이 특성을 이용해 사용자를 인증하는 데 사용할 수 있다.

공개키는 왜 공개해도 되는가?
암호화된 공개키를 공개해도 복호화를 위한 개인키를 구하는데 시간이 너무 오래 걸려 현실적으로 찾을 수 없다고 판단하기 때문

비교	비밀키 암호화	공개키 암호화
키 개수	한 개의 키를 사용	두 개의 키를 사용
키 보관	개인이 비밀리에 보관	개인키는 비밀리에 보관하지만 공개키는 어디든지 배포 가능
키 길이	56비트, 128비트 등	512, 1024, 2048 비트
암호화/복호화 속도	빠름	느림
암호화 할 수 있는 평문의 길이	제한 없음	제한 있음
기밀성	가능함	가능함
인증	부분적 가능함	가능함
무결성	부분적 가능함	가능함
부인방지	불가능함	가능함

4.2. 왜 HTTPS Handshake 과정에서는 인증서를 사용하는 것 일까요?

참고 자료

• CloudFlare - TLS 핸드셰이크의 원리는 무엇일까요? | SSL 핸드셰이크
• HTTPS 통신과정 쉽게 이해하기 #3(SSL Handshake, 협상)

인증서를 사용하는 이유
웹 서버와 클라이언트 간의 안전하고 신뢰할 수 있는 통신을 보장
HTTPS는 HTTP 프로토콜에서 SSL/TLS을 추가하여 보안을 강화한 프로토콜

1. 데이터 암호화 ( Data Encryption )
   전송되는 데이터의 기밀성을 보장하며 인증서는 공용 키 암호화를 사용하여 클라이언트와 서버 간에 안전한 통신 채널을 설정
2. 서버 신원 인증 ( Server Authentication )
   인증서는 신뢰할 수 이쓴 기간(CA, 인증 기관)이 발행한 것으로, 서버의 신원을 보장합니다.
   이를 통해서 MITM 공격을 방지할 수 있습니다.
3. 데이터 무결성 ( Data Integrity )
   인증서는 데이터가 전송 중 변조되지 않았음을 보장합니다.

4.3. SSL과 TLS의 차이는 무엇인가요?

참고 자료 : AWS - SSL과 TLS의 차이점은 무엇인가요?

SSL ( Secure Sockets Layer )
보안 소켓 통신(SSL)은 네트워크상의 두 디바이스 또는 애플리케이션 간에 보안 연결을 생성하는 통신 프로토콜 또는 규칙 세트입니다.

TSL ( Transport Layer Security )
전송 계층 보안(TSL)은 기존 SSL 취약성을 수정하는 업그레이된 SSL 버전입니다. TLS는 더 효율적으로 인증하고 암호화된 통신 채널을 계속 지원

4.3.1. SSL/TLS 핸드셰이크

SSL 핸드셰이크는 명시적 연결인 반면 TLS 핸드셰이크는 암시적 연결입니다. SSL 핸드셰이크 프로세는 TLS 프로세스보다 단계가 더 많았습니다. TLS는 추가 단계를 제거하고 총 암호 그룹 수를 줄여서 프로세스 속도를 높였습니다.

4.3.2. 알림 메시지

SSL 및 TLS 프로토콜은 알림 메시지를 통해 오류와 경고를 전달합니다.

SSL에는 경고와 치명적이라는 두 가지 알림 메시지 유형만 있습니다. 경고 알림은 오류가 발생했지만 연결을 계속할 수 있음을 나타냅니다. 치명적 알림은 연결을 즉시 종료해야 함을 나타냅니다. 또한 SSL 알림 메시지는 암호화되지 않습니다.

TLS에는 닫기 알림이라는 추가 알림 메시지 유형이 있습니다. 닫기 알림은 세션 종료를 알립니다. 또한 TLS 알림은 추가 보안을 위해 암호화됩니다.

4.3.3. 메시지 인증

SSL과 TLS 모두 메시지의 진본성과 무결성을 확인하기 위한 암호화 기술인 메시지 인증 코드(MAC)를 사용합니다. 레코드 프로토콜은 보안 키를 사용하여 MAC을 고정 길이 코드로 생성하고 원본 메시지에 첨부합니다.

SSL 프로토콜은 MAC 생성에 MD5 알고리즘(현재는 구식)을 사용합니다. TLS는 더 복잡한 암호화와 보안에 해시 기반 메시지 인증 코드(HMAC)를 사용합니다.

4.3.4. 암호 그룹

암호 그룹은 브라우저와 서버 간의 정보를 암호화하기 위한 키를 생성하는 알고리즘 모음입니다. 일반적으로 암호 그룹에는 키 교환 알고리즘, 검증 알고리즘, 대량 암호화 알고리즘 및 MAC 알고리즘이 포함됩니다. 보안 문제로 인해 TLS의 여러 알고리즘이 SSL에서 업그레이드되었습니다.

⭐ INFO

현재 SSL은 공식적으로 사용종료가 되었으며 TSL을 사용하고 있습니다.