14장) 보안 HTTP
HTTP를 안전하게 만들기
안전한 http를 만들기 위해선 다음과 같은 고려사항들이 있다.
- 서버 인증: 위조된 서버가 아님을 인증
- 클라이언트 인증: 위조된 클라이언트가 아님을 인증
- 무결성: 데이터 위조 방지
- 암호화: 도청에 대한 걱정 없이 대화
- 효율: 저렴한 클라이언트 & 서버를 지원하는 빠른 알고리즘
- 편재성 (Ubiquity)
- 관리상 확장성: 누구나 어디서든 즉각적인 보안 통신 가능
- 적응성: 현재 알려진 최선의 보안 방법 지원
- 사회적 생존성: 사회적, 문화적, 정치적 요구 만족
HTTPS
HTTPS는 HTTP의 하부에 전송 레벨 암호 보안 계층을 제공하며, 이 보안 계층은 안전 소켓 계층 (SSL) 혹은 그를 계승한 전송 계층 보안 (TLS)를 이용하여 구현된다. 어려운 인코딩, 디코딩 작업은 대부분 이 계층에서 일어나기 때문에 대부분의 경우 클라이언트나 서버의 로직을 변경할 필요는 없다.
디지털 암호학
어쨌든 https는 암호화와 관련이 있기 때문에 관련된 용어에 대한 정리가 필요하다.
| 용어 | 뜻 |
|---|---|
| 암호 | 텍스트를 아무나 읽지 못하도록 인코딩하는 알고리즘 |
| 키 | 암호의 동작을 변경하는 숫자로 된 매개변수 |
| 대칭키 암호 체계 | 인코딩과 디코딩에 같은 키를 사용하는 알고리즘 |
| 비대칭키 암호 체계 | 인코딩과 디코딩에 다른 키를 사용하는 알고리즘 |
| 공개키 암호법 | 비밀 메시지를 전달하는 수백만 대의 컴퓨터를 쉽게 만들 수 있는 시스템 |
| 디지털 서명 | 메시지가 위조 혹은 변조되지 않았음을 입증하는 체크섬 |
| 디지털 인증서 | 신뢰할 만한 조직에 의해 서명되고 검증된 신원 확인 정보 |
대칭키 암호법
대칭키 암호에서는 발송자와 수신자 모두 통신을 위해 비밀 키를 똑같이 공유해야 한다. 하지만 이 키의 경우 요즘처럼 컴퓨터의 연산 처리가 빨라지는 시대에는 무차별 대입 등으로 뚫릴 수도 있고, 발송자와 수신자가 쌍을 이룰 때마다 키를 생성하고 관리해야해서 리소스가 많이 든다.
공개키 암호법
공개키 암호법은 두 개의 비대칭 키를 사용한다.
- 호스트의 메시지를 인코딩하기 위한 키 (모두를 위해 공개되어 있다)
- 대부분의 경우 공개 키는 디지털 인증서 안에서 찾는다
- 호스트의 메시지를 디코딩하기 위한 키 (호스트만이 알고 있다)
즉, 메시지의 인코딩은 누구나 할 수 있지만, 메시지의 디코딩은 소유자만이 가능하다.
RSA
공개키 비대칭 암호는 아래의 세 가지가 노출되었다 하더라도 비밀인 개인 키를 계산할 수 없어야 한다.
- 공개 키 (말 그대로 공개되어 있다)
- 가로챈 암호문
- 메시지와 그것을 암호화한 암호문
혼성 암호 체계와 세션 키
공개 키 암호 방식의 알고리즘은 계산이 느린 경향이 있기 때문에 실제로는 의사소통 채널을 수립할 때는 편리하게 공개 키 암호를 사용하고, 이후 안전한 채널 안에서는 임시의 무작위 대칭 키를 생성하고 교환하기도 한다.
디지털 서명
디지털 서명은 메시지에 붙어있는 특별한 암호 체크섬이다.
- 메시지를 작성한 저자를 알려준다. 저자는 극비 개인 키를 갖고 있기 때문에, 오직 저자만이 이 체크섬을 계산할 수 있다.
- 메시지 위조를 방지한다. 메시지가 송신 중 수정된다면 체크섬이 일치하지 않는다.
서명된 메시지 전달 흐름 (A → B)
- A는 가변 길이 메시지를 정제하여 고정된 길이의 요약(digest)를 만든다.
- A는 1번의 요약에 개인 키를 매개변수로 하는 서명 함수를 적용한다.
- A는 계산된 서명을 메시지의 긑에 덧붙이고, 메시지와 서명 모두 B에게 전송한다.
- B는 확인을 위해 서명을 검사할 때 공개키를 이용한 역함수를 적용한다. B가 갖고 있는 요약과 풀어낸 요약이 다르다면 메시지가 위조되거나 발송자가 키를 가지고 있지 않다는 의미이다.
🤔 왜 개인 키를 사용하는 디코딩 함수로 서명을 할까?
RSA 암호 체계에서는 개인 키를 입력으로 취하는 디코더 함수 D가 서명 함수로 사용된다. 디코더 함수도 결국은 어떠한 입력과도 사용될 수 있는 단순한 함수이고, RSA 암호 체계에서는 디코더, 인코더 함수가 어떤 순서로 적용되든 서로의 결과를 취소한다.
결국 -1, +1 되면서 평문으로 되돌아 오고, 이렇게 확인된 평문을 처음에 받은 평문과 확인하여 일치하면 해당 공개 키와 쌍을 이루는 개인 키임을 알 수 있다.
디지털 인증서
디지털 인증서는 신뢰할 수 있는 기관으로부터 보증 받은 사용자나 회사에 대한 정보를 담고 있다 (대상의 이름, 유효 기간, 인증서 발급자, 인증서 발급자의 디지털 서명 등을 포함한다).
추가로, 인증서는 대상과 사용된 서명 알고리즘에 대한 서술적인 정보 뿐 아니라 보통 대상의 공개 키도 담고 있다.
엄밀하게 정해진 단인 표준은 없고, 보통은 X.509라는 표준화된 서식에 저장하고 있다.
서버 인증을 위해 인증서 사용하기
- 최신 브라우저는 자동으로 접속한 서버에서 디지털 인증서를 가져온다. 서버가 인증서를 갖고 있지 않다면, 보안 커넥션은 실패한다.
- 브라우저들은 여러 서명 기관의 인증서가 미리 설치된 채로 출하된다.
- 모르는 서명기관이라면 브라우저는 대개 사용자가 서명 기관을 신뢰하는지 확인하기 위한 대화상자를 보여준다.
HTTPS의 세부사항
HTTPS는 HTTP 프로토콜에 대칭, 비대칭 인증서 기반 암호 기법의 강력한 집합을 결합한 것이다. HTTPS는 HTTP 메시지를 TCP로 보내기 전에 먼저 그것을 암호화하는 보안 계층으로 보낸다. 오늘날의 보안 계층은 SSL과 이를 계승하는 TLS가 있는데 이를 포괄하여 SSL로 지칭하고 있다.
HTTPS 스킴
URL의 스킴 접두사가 https:// 로 시작하는지를 확인한다. HTTPS는 기존에 80번 포트로 연결하던 통신을 443 포트로 연결한다. 그 후 서버와 바이너리 포맷으로 된 몇몇 SSL 보안 매개변수를 교환하면서 핸드쉐이크를 하고 암호화된 HTTP 명령이 뒤를 잇는다.
SSL 핸드셰이크
암호화된 메시지를 주고받기 전에 클라이언트와 서버는 SSL 핸드셰이크를 통해 다음과 같은 일련의 과정을 진행한다.
- 프로토콜 버전 번호 교환
- 양쪽이 알고 있는 암호 선택
- 양쪽의 신원을 인증
- 채널을 암호화하기 위한 임시 세션 키 생성
메시지 암호화를 위해선 세션 키가 필요한데 이는 SSL 핸드셰이크 후 이루어진다.
OpenSSL
OpenSSL은 SSL에서 가장 인기 있는 오픈 소스로, 강력한 다목적 암호법 라이브러리이니 동시에 SSL과 TLS 프로토콜을 구현한 사용 수준의 툴킷이다.
프락시를 통한 보안 트래픽 터널링
프락시를 거치는 경우, 클라이언트는 먼저 프락시에게 암호화되지 않은 평문으로 자신이 연결하고자 하는 안전한 호스트와 포트를 말해준다. 이 때 HTTP는 CONNECT라는 새로운 확장 메서드를 이용한다.
'웹' 카테고리의 다른 글
| Storybook 빌더 비교 (Vite, Webpack) (0) | 2023.04.23 |
|---|---|
| src가 없는 img 요소 대체하기 (pseudo-element, safari 해결방법) (0) | 2023.03.26 |
| Vue 컴포넌트 npm 패키지로 배포하기 (0) | 2021.04.04 |
| (서버 API가 아직 개발중이라면) MSW로 Mock API 제작하기 (3) | 2021.02.28 |