CS/🖥 네트워크

🖥 HTTP 와 HTTPS

늦은산책 2023. 9. 25. 17:55

💬 HTTP(Hypertext Transfer Protocol)

서버 / 클라이언트 모델을 따라 데이터를 주고 받기 위한 프로토콜이다.

Hypertext : 다른 페이지의 링크를 담고 있는 문서
Transfer : 이동통신
Protocol : 규약

HTTP는 인터넷에서 하이퍼 텍스트를 교환하기 위한 통신 규약으로, 80번 포트를 사용하고 있다. 따라서 HTTP 서버가 80번 포트에서 요청을 기다리고 있으며, 클라이언트는 80번 포트로 요청을 보내게 된다.

 

HTTP는 텍스트, 이미지, 영상, JSON 등 거의 모든 형태의 데이터를 전송할 수 있다.

현제 HTTP/1.1이 가장 보편화 되어있으며 현재는 HTTP/2를 거쳐 3까지 개발이 되어있다. 하지만 1.1을 많이 사용하는 모습을 볼 수있다.

 

HTTP의 특성

1. 비연결성

클라이언트와 서버가 한 번 연결을 맺은 후에 요청이 끝나게 되면 연결을 끊어버린다.

  • 끊는 이유
    • 서버에서 다수의 클라이언트와 연결 지속시 많은 리소스가 발생한다. 그래서 서버가 응답을 마친 후 연결을 끊어 연결 유지를 위한 리소스를 줄이고 더 많은 연결을 할 수 있게 되는 것이다.
  • 모든 요청에 새로운 연결
    • 이런식으로 연결을 자주 끊게 되면 그만큼 자주 연결을 해야한다. 이것이 쌓이게 되면 연결 해제에 대한 오버헤드 발생한다.
    • 이를 해결하기 위해 패킷을 주기적으로 보내게 되는데 만약 안부를 묻는 패킷에 답장이 없다면 접속을 끊는 방식을 사용한다. 하지만 이또한 주기적으로 패킷을 보내고 확인해야하기 때문에 서버가 많은 양의 데이터를 처리하는 과정에 process의 수가 늘어나게 되고 keep alive를 유지하기 위한 메모리가 증가하게 되며 주의해야한다.

 

2. 무상태 프로토콜

Connectionless로 인해 서버가 두 요청간의 어떠한 데이터도 유지하지 않아 서버는 연결됐었던 클라이언트도 인지하지 못한다

  • 매번 새로운 인증
    • 예를 들어 로그인을 해야만 사용할 수 있는 서비스를 위해 로그인을 한다고 하더라도 다른 서비스를 사용할때 요청엔 로그인을 한 상태를 기억하지 못하기 때문에 매번 로그인을 진행해주어야 한다.
    • 이를 해결하기 위해 cookie와 session을 사용해서 기억을 하게 된다. 하지만 이 방법은 데이터를 안전하게 저장하지 못해서 안전하게 사용해야 하는 데이터인 경우 토큰을 사용하게 된다.

 

HTTP의 흐름

  1. TCP 연결을 열어준다. ( 새연결 or 기존 연결을 재사용 )
  2. HTTP 메세지를 전송한다.
  3. 서버가 보낸 응답을 읽는다
  4. 연결을 닫거나 다른 요청을 위해 재사용한다.

 

HTTP 메세지

HTTP 메세지는 크게 request와 response로 나뉜다. request를 예시로 구조를 간단하게 살펴보자

 

HTTP 메서드

  • GET : 주로 데이터를 요청하는 상황에 많이 사용한다
  • POST : 데이터를 입력하는데 많이 사용한다
  • PUT : 데이터를 수정하는데 많이 사용한다.
  • DELETE : 데이터를 삭제할 때 많이 사용한다.
GET VS POST
GET의 경우 ?뒤에 QueryString을 통해 값을 입력하게 전송한다. 이는 URI에 전부 보이게 되면서 데이터 보안적으로 굉장히 좋지 않다.
POST는 전송데이터를 Body라는 곳에 담아서 보내게 되는데 이는 사람의 눈으로 보이지 않는다. 때문에 데이터 보안적으로 좀 더 좋다고 할 수 있다. (하지만 개발자 도구를 사용하면 전부 보이기 때문에 암호화를 거쳐야 한다)

 

❓ HTTP가 보안적으로 안전할까?

우리가 인터넷을 할 때 많이 보게 되는것은 HTTP가 아닌 HTTPS이다. 왜 HTTP가 아닌 HTTPS일까 그것은 보안적인 문제가 가장 큰 이유가 된다. HTTP는 클라이언트와 서버간의 통신에 있어서 별다른 보안 조치가 없기 때문에 만약 누군가 네트워크 신호를 가로챈다면 HTTP의 내용은 그대로 외부로 노출이 된다. 이는 중요 정보가 따로 없는 토이 프로젝트의 경우 큰 상관이 없겠지만 고객의 개인정보나 비밀을 취급하는 대규모 서비스라면 큰 보안적 허점이 발생하게 된다. 때문에 보안적으로 더 강한 HTTPS를 사용하는 것이다.

 

 

💬  HTTPS(Hypertext Transfer Protocol Secure)

HTTP는 전송되는 정보를 암호화하지 않는다 이건 정보를 쉽게 도난 당할 수 있다는 뜻을 의미하게 되고 HTTP에서 모든 요청과 응답을 SSL이나 TLS를 사용해서 암호화를 시키는 것이다

 

기존의 HTTP 프로토콜은 전송계층의 TCP위에서 동작하게 된다. 여기서 SSL(Secure Sokets Layer)이라는 보안계층이 전송 계층 위에 올라가게 된다. HTTP는 SSL위에 HTTP를 얹어서 보안이 보장된 통신을 하는 프로토콜이다. 이를 SSL 암호화 통신이라고 하고 SSL 암호화 통신은 공개키 암호화 방식이라고 한다.

 

또한 HTTP와는 다르게 443 포트 번호를 사용하고 있다.

 

대칭키 암호화와 비대칭키 암호화

  • 대칭키 암호화
    • 클라이언트와 서버가 동일한 키를 사용하며 암호화 / 복호화를 진행한다
    • 키가 노출되면 매우 위험하지만 매우 빠른 연산 속도를 자랑한다.
  • 비대칭키 암호화 ( 공개키 암호화 )
    • 1개의 쌍으로 구성된 공개키와 개인키를 암호화 / 복호화 하는데 사용한다
    • 키가 노출되어도 비교적 안전하지만 연산 속도가 느리다는 단점이 존재한다.

SSL

웹 사이트와 브라우저 사이에 전송된 데이터를 암호화하여 인터넷 연결의 보안을 유지하는 표준 기술이다. 이는 해커가 개인 정보 및 금융 정보를 포함한 전송되는 모든 정보를 열람하거나 훔치는 것을 방지한다.

 

❓ 왜 공개키(비대칭키)는 대칭키보다 느릴까?

비대칭키의 대표적인 알고리즘은 RSA, 디피 - 헬만, 타원 곡선 암호 등이 있다.

여기서도 가장 대표적인 RSA

기본적인 정수로 소수를 이용한다. 중요 정보를 두 새의 소수로 표현한 후에 두 소수의 곱을 힘트와 함께 암호로 전송한다. c = a * b일때 a와 b로는 c를 쉽게 구할 수 있지만 c만을 가지고 a 와  b를 알아내기 쉽지 않다. 이것을 토대로 c는 공개키 a는 개인키 라고 생각하면 편할 것이다.

수학적 난제를 기반으로 설계된 비대칭키는 암호화나 복호화를 수행하기 위한 연산이 복잡한 수학 연산을 기반으로 구성되어 있기 때문에 효율성이 대칭키 암호(AES, SEED)에 비해 1000배에 달한다. 하지만 비대칭키는 길이가 긴 키의 소인수 분해가 쉽지 않다는 특성을 활용한 알고리즘인 만큼 대칭키에 비해 키의 사이즈가 크고 연산이 복잡하다. 
대칭키의 대표적 알고리즘 AES는 128, 192, 256비트 크기의 키를 사용한다. 반면 비대칭의 경우 512, 1024, 2048 비트의 키를 사용한다.

따라서 비대칭키를 사용한 암호화, 복호화는 대칭키의 사용보다 부하가 크고, 사용에 제약이 따르게 된다.

 

❓ HTTPS의 동작 과정

HTTPS는 대칭키와 비대칭키를 모두 사용해서 빠른 연산 속도와 안정성을 가지고 있다. 

HTTPS 연결 하는 과정에서 먼저 서버와 클라이언트는 세션키를 교환한다. 세션키는 주고 받는 데이터를 암호화하기 위해 사용되는 대칭키이고 데이터간의 교환에는 빠른 연산 속도가 필요하기 때문에 세션키는 대칭키로 만들어진다.

 

이 세션키를 클라이언트와 서버가 어떻게 교환할 것이냐 인데, 이 과정에서 비대칭키가 사용된다

 

즉, 처음 연결을 성립하여 안전하게 세션키를 공유하는 과정에서 비대칭키가 사용된다.

이후 데이터를 교환하는 과정에서 빠른 연산 속도를 위해 대칭키가 사용된다.

 

 

과정을 순서로 보자면

  1. 클라이언트(브라우저)가 서버로 최초 연결 시도를 한다
  2. 서버는 공개키(SSL 인증서)를 브라우저에게 넘겨준다. 
    • CA - 서버 운영 기업이 넘겨준 공개키를 인증서 발급자
      CA의 이름 등과 함께 묶어 CA가 가지고 있는 개인키로 암호화해서 SSL 인증서를 발급해준다.
  3. 브라우저는 공개키(SSL 인증서)의 유효성을 검사하고 세션키를 발급한다
    • 유효성 검사 과정
      브라우저는 대표적인 CA들의 리스트와 그들의 공개키를 보유하고 있다, 만약 CA의 이름과 브라우저가 소유하고 있는 CA 이름이 같다면 CA의 공개키로 SSL 인증서를 복호화한다.
  4. 브라우저는 세션키를 보관하며 추가로 서버의 공개키로 세션키를 암호화하여 서버로 전송한다.
  5. 서버의 개인키로 암호화된 세션키를 복호화하여 세션키를 얻는다
  6. 클라이언트와 서버는 동일한 세션키를 공유하므로 데이터를 전달할 때 세션키로 암호화 / 복호화를 진행한다.