http 완벽가이드 2회독 중 나왔던 질문들
- 대칭키-비대칭키 / 비밀키 / 공개키-개인키
- 디지털 서명과 JWT
- ec2에 접속할때 pem키는 무엇일까
- ssh
- ssl 핸드셰이킹
- 터널링
- https 의 기본 포트번호가 443인 이유
대칭키-비대칭키 / 공개키-개인키 / 비밀키
대칭키 암호화는 암호화할때와 복호화할때 사용하는 키가 같은 암호화 방법이고, 비대칭키 암호화는 암호화할때와 복호화할때 사용하는 키가 다른 암호화 방법이다.
클라이언트와 서버가 대칭키 암호화 방법으로 암호화/복호화를 할때의 키를 비밀키라고 한다.
이러한 방법을 이용하게 되면 모든 클라이언트-서버 사이에 키가 하나씩 있어야 하므로 관리해야할 키의 개수가 늘어나게 된다.
반대로, 비대칭키 암호화에서는 모두에게 공개된 공개키를 이용해 암호화하고, 수신측은 자신의 개인키를 이용해 복호화할 수 있다.
개인키는 자신만 알고 있으므로 공개키로 암호화된 메세지가 탈취당하더라도 개인키 없이는 복호화할 수 없다.
이 방법은 서버의 공개키/개인키 쌍만 있으면 되기 때문에 관리해야할 키의 개수가 적다는 장점이 있다.
디지털 서명과 JWT
이 그림을 보고 jwt와 비슷하다는 것을 발견했다.
JSON Web Token(JWT)는 header/payload/signature 세 부분으로 나뉜다.
header 에는 토큰의 타입과 서명에 사용한 알고리즘의 종류가 포함된다.
payload 에는 사용자를 식별하기 위한 사용자에 대한 정보가 포함된다.
signature 에는 header와 payload의 정보를 서버의 개인키로 암호화한 것이 포함된다.
jwt는 위의 정보들을 Base64Url 로 인코딩하여 생성된다.
따라서 디코딩했을시에 payload부분이 그대로 노출되게 된다. 위의 디지털 서명 그림에서도 평문메세지는 암호화되지 않았다는 것을 알 수 있다. payload에는 중요한 개인 정보를 담으면 안되는 것을 알 수 있다.
그럼 jwt의 목적은 무엇일까 ?
디지털 서명 부분을 이용해 토큰이 유효한지를 알 수 있다.
서버만이 가지고 있는 키를 이용해야지만 signature를 디코딩할 수 있으므로 서버는 토큰이 중간이 위조되었는지를 알 수 있다. 이것이 신뢰할 수 있는 사용자임을 보증할 수 있는 방법이다.
SSL Hand-Shaking
설명에 앞서
인증서는 어디에 이용되고 어떤 정보를 담고 있을까
인증서는 신뢰할 수 있는 서명기관이 발급한 해당 서버에 대한 인증서를 말한다.
서버의 신원 증명자?보증인? 이라고 할 수 있다.
인증서는 인증기관 자신에 대한 정보와 진짜 자신이 발급한 인증서가 맞는지를 검증하기 위한 발급자의 서명을 가진다. 또한 신뢰할 수 있다고 보증하는 서버의 공개키를 가지고 있다.
https 프로토콜을 이용해 암호화된 메세지를 주고 받으며 보안 수준을 높일 수 있다.
그렇다면 클라이언트와 서버간의 암호화는 어떻게 이루어지는 것일까
위 그림과 같은 계층구조에서 http, https 모두 tcp 커넥션 위에서 동작한다.
두 엔드포인트간의 https 커넥션을 크게 보자면
- TCP 커넥션을 맺는다.
- SSL 핸드셰이킹을 통해 비밀키를 생성한다.
- 송신측은 비밀키를 이용해 보내는 메세지를 암호화한다.
- TCP 커넥션을 통해 메세지를 전달한다.
- 수신측은 비밀키를 이용해 받은 메세지를 복호화한다.
- 통신이 끝났으면 ssl커넥션을 닫고 tcp 커넥션을 닫는다.
이 과정에서 SSL 핸드셰이킹이 필요한 이유는 두 컴퓨터가 공유하는 대칭키를 안전하게 주고 받기 위함이다.
참고로 3-way-handshaking을 통해 tcp 커넥션을 이미 맺은 상태이다.
- 클라이언트는 서버로 cipher suite 들과 인증서를 요구하는 요청을 보낸다.
- 서버는 cipher suite중 하나를 선택하고 인증서와 함께 응답으로 보낸다.
- 클라이언트는 선택받은 암호를 이용해 비밀키(대칭키)를 생성하고, 이를 인증서에 있던 서버의 공개키로 암호화하여 보낸다.
- 서버는 개인키를 가지고 있으므로 복호화하여 클라이언트에서 생성한 비밀키를 알아낼 수 있다.
ssl 핸드셰이킹이 끝난 후, 클라이언트와 서버는 같은 비밀키를 공유하게 되고, 이를 이용해 요청과 응답을 둘 만 아는 비밀키로 암호화하여 보낼 수 있게 된다.
https 의 기본 포트번호가 443인 이유
일반적으로 http 프로토콜은 80번 포트를 이용한다. 만약 https 프로토콜도 똑같이 80번 포트를 이용한다면 어떻게 될까 ?
http 메세지는 어떤 구조체를 이용한 것이 아니라 단순히 CRLF로 구분되는 문자열에 불과하다.
이때 시작줄부터 본문끝까지 알아볼 수 없도록 암호화 된 https 메세지가 http와 같은 80번 포트를 통해 전달된다면, https 메세지 전체가 http 메세지의 본문의 일부라고 잘못 여겨질 가능성이 있다.
따라서 두 프로토콜은 서로 다른 포트로 커넥션을 맺을 필요가 있다.
