HTTPS

HTTP

HTTP는 요청(Request)와 응답(Response)로 구성되어 있고, 클라이언트가 요청을 하면 서버가 응답을 하는 구조로 되어 있다. HTTP는 FTP나 텔넷과는 다르게 비연결식이다. FTP나 Telnet은 클라이언트가 서버에 정보를 요청해도 서버가 클라이언트와 연결을 끊지 않지만, HTTP는 클라이언트가 서버에 정보를 요청하면 응답 코드와 내용을 전송하고 클라이언트와 연결을 종료한다.

https://mangkyu.tistory.com/98

TLS

RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2

https://m.blog.naver.com/hw5773/220417842217

TLS의 주된 목적은 두 개의 양단 애플리케이션 사이에 프라이버시와 데이터 무결성을 제공하는 것이다. 프로토콜은 두 개의 레이어로 구성되어 있다. 하나는 TLS Record 프로토콜이고 하나는 TLS Handshake 프로토콜이다.

특정 신뢰할 수 있는 트랜스포트 레이어 위에 있는 가장 하위 레벨에는 TLS 레코드 프로토콜이 자리 잡는다. TLS 레코드 프로토콜은 두 가지 특성을 가진 연결 보안을 제공한다.

연결은 사적이다. 대칭 암호학(AES, RC4 등등)이 데이터 암호화에 사용된다. 대칭 암호화를 위한 키들은 각각의 연결에 대해 유일하게 생성되고 다른 프로토콜(예를 들어, TLS 핸드쉐이크 프로토콜)에 의해 비밀리에 협상된다. 레코드 프로토콜은 암호화 없이 사용될 수 있다.
연결은 신뢰할 수 있다. 메시지 전송은 키가 있는 MAC을 사용한 메시지 무결성 검사를 포함한다. 안전한 해시 함수들(예를 들어, SHA-1 등)이 MAC 계산에 사용된다. 레코드 프로토콜은 MAC 없이 작동할 수 있으나, 다른 프로토콜이 레코드 프로토콜을 보안 파라미터를 협상하기 위해 전송으로써 사용되는 한 일반적으로 이 모드로 사용된다.

TLS 레코드 프로토콜은 다양한 고 수준의 프로토콜의 캡슐화에 사용된다. 하나의 캡슐화 프로토콜로써 TLS 핸드쉐이크 프로토콜은 서버와 클라이언트가 상호 인증하도록 하고 애플리케이션 간에 첫 데이터를 주고 받기 전에 암호화 알고리즘과 암호 키를 협상한다. TLS 핸드쉐이크 프로토콜은 다음의 세 가지 특성을 가진 연결 보안을 제공한다.

연결 상대의 정체가 비대칭적 혹은 공개키 암호화 (예를 들어, RSA, DSA 등)를 사용하여 인증된다. 이 인증은 선택적으로 될 수 있으나, 일반적으로 적어도 하나의 개체에 대해서 요구된다.
공유키의 협상은 비밀리에 진행된다. 협상된 공유키는 도청자에 의해 사용 불가능하다. 그리고 이는 또한 공유키가 얻어질 수 없는 임의의 인증된 연결이나 연결 중간에 있는 공격자에 의해서도 불가능하다.
협상은 신뢰할 수 있다. 어떠한 공격자도 통신에서의 파티에 의해 탐지되지 않고 협상 통신을 수정할 수 없다. (즉, 공격자에 의한 위변조가 발생하면 양 종단은 알아차릴 수 있으며, 이는 Finish 단계의 해시를 통해 알 수 있다.)

질문

TLS의 서버 측을 처리하는 구현체는 인프라 아키텍처 상 어디에?