[ FastAPI ] HTTPS

HTTPS가 단지 "가능"한지 여부는 쉽게 추측할 수 있을 것 같습니다.

 

그러나 이것은 생각보다 더 복잡합니다.

 

팁
급하거나 신경 쓰지 않는다면, 다음 섹션으로 넘어가 다른 기술로 모든 것을 설정하는 단계별 지침을 따르시면 됩니다.

 

사용자 관점에서, HTTPS의 기본을 배우기 위해서는, https://howhttps.works/ko/ 을 확인하시기 바랍니다.

 

이제, 개발자 관점에서, HTTPS에 관해 생각할 때 염두에 두어야 할 몇 가지 사항이 있습니다:

 

• HTTPS을 위해서는, 서버에 제삼자에 의해 생성된 "인증서"가 있어야 합니다.
  • 이러한 인증서는 실제로 "생성된" 것이 아니라, 제삼자를 통해 획득합니다.
• 인증서는 유효 기간이 존재합니다.
  • 따라서 만료될 수 있습니다.
  • 그리고 갱신되어야 하며, 제삼자를 통해 다시 획득해야 합니다.
• 연결 암호화는 TCP 수준에서 발생합니다.
  • 그것은 HTTP 밑의 한 계층입니다.
  • 따라서, 인증서와 암호화는 HTTP 이전에 처리됩니다.
• TCP는 "도메인"에 관해 알지 못합니다. 오로지 IP 주소만 알 뿐입니다.
  • 요청된 특정 도메인에 관한 정보는 HTTP 데이터에 포함됩니다.
• HTTPS 인증서는 특정 도메인을 "인증" 하지만, 프로토콜 및 암호화는 어떤 도메인을 처리 중인지 알기 전에, TCP 단계에서 처리됩니다.
• 기본적으로, 그것은 IP 주소당 오로지 하나의 HTTPS 인증서를 가질 수 있다는 걸 의미합니다.
  • 서버가 얼마나 크거나 각 애플리케이션이 얼마나 작든 상관 없습니다.
  • 그러나, 이를 해결할 방법은 존재합니다.
• SNI라는 TLS 프로토콜 (HTTP 이전의 TCP 단계에서 암호화를 처리하는 프로토콜) 에 대한 확장이 있습니다.
  • 이러한 SNI 확장은 (단일 IP 주소를 사용한) 하나의 단일 서버가 여러 HTTPS 인증서를 가지고 다수의 HTTPS 도메인/어플리케이션을 제공하는 걸 가능하게 해줍니다.
  • 이렇게 작동하기 위해, 공용 IP 주소에서 리스닝 중이고 서버에서 실행 중인 단일 컴포넌트 (프로그램) 에 서버의 모든 HTTPS 인증서가 있어야 합니다.
• 보안 연결을 얻은 이후에도, 통신 프로토콜은 여전히 HTTP입니다.
  • HTTP 프로토콜을 통해 전송됨에도 불구하고, 내용은 암호화 됩니다.

 

하나의 프로그램/HTTP 서버가 서버 (머신, 호스트, 기타 등등) 에서 실행되고 모든 HTTPS의 부분 : 동일한 서버 내에서 실제 실행 중인 HTTP 애플리케이션 (이 경우, FastAPI 애플리케이션) 에 송신하는 복호화 된 HTTP 요청, 애플리케이션으로 부터의 응답 수신, 적절한 인증서를 사용한 암호화 및 HTTPS을 사용하여 클라이언트로의 재송신을 관리하는 건 일반적인 사례입니다. 이러한 서버는 종종 TLS 터미네이션 프록시라 불립니다.

 

Let's Encrypt

Let's Encrypt 이전에, HTTPS 인증서들은 신뢰된 제삼자에 의해 판매되었습니다.

 

이러한 인증서를 취득하는 과정은 자주 번거롭고, 상당한 서류 작업을 요구했으며 비쌌습니다.

 

그러나 Let's Encrypt가 만들어졌습니다.

 

이것은 Linux 제단의 프로젝트입니다. 자동화된 방식으로 HTTPS 인증서를 무료로 제공합니다. 이 인증서는 모든 표준 암호화 보안을 사용하며, (3개월 정도로) 수명이 짧고, 따라서 단축된 수명으로 보안이 실제로 더 좋습니다.

 

도메인은 안전하게 확인되고 인증서는 자동으로 생성됩니다. 또한 인증서의 갱신을 자동화할 수 있습니다.

 

이러한 아이디어는 인증서 취득 및 갱신을 자동화하여, 결국 안전한 HTTPS를, 무료로, 영원히 사용할 수 있도록 하는 것입니다.