SSL TLS 기본에 대한 강의다! (완전 친절)
1. TLS가 무엇일까?
위와 같이 예를 들어 보자. 사용자가 http://my-bank.com 서버로 개인정보를 이용하여 (1번) 로그인을 시도하면,
랜덤 숫자들(2번)을 통해 내 키가 'LKJSDFK: XZKJSDLF'로 암호화 된다(3번. encrypted).
그리고 그 암호화된 정보가 server로 전달된다.
* 그럼 중간에 해커가 정보를 가로채더라도, 암호화되어있기 때문에 해당 정보를 식별할 수 없다.
다만, 서버 또한 해당 key를 식별할 수 없다.
그래서, 랜덤 숫자 key까지 함께 보내줘서 decrypt하게 한다.
다만, 이렇게 될 경우 해커 또한 decrypt를 할 수 있다.
=> 이 방법이 Symmetric encryption 이다.
1. Symmetric encryption은
양단(encrypt, decrypt)에서 동일한 key를 사용하기 때문에 해킹이 가능하고,
key도 노출되기에 매번 바꾸어주어야 한다.
그래서 다른 방법을 알아보자.
2. Asymmetric Encryption
양단 간의 key를 'Private Key', 'Public Lock'로 분리했다.
Public Lock은 누구나 접근 가능하지만, 기 associated된 private key만 unlock을 할 수 있다.
예시를 한번 들어보자.
서버에 접근할 때, id/pw를 사용하고 싶지 않아 유저는 ssh-key를 generate한다.
#ssh-keygen
그럼 id_rsa 이라는 private key와 id_rsa.pub라는 public lock이 생성된다.
그런데, 유저들이 많아지면 어떻게 할까? (아래 핑크색 유저)
server에도 또 다른 문이(public lock) 또 생긴다.
서버 입장에서도 public lock을 생성해야 하므로 아래 커멘드를 사용하여 key를 만든다.
#openssl genrsa -o
그럼, 유저가 https를 사용하여 web server에 처음 접근할 때, 서버로부터 public key를 얻는다.
근데 해커도 public key를 카피할 수는 있다.
그리고 유저는 해당 key를 이용하여 정보를 암호화하고, 이를 서버에 보낸다.
해커 또한 이 정보를 사용할 수 있겠다.
그러나, 해커는 키를 decrypt하고 symmetric key를 조회하기 위한 private key를 가지고 있지 않다.
즉, 해커는 only public key만 가지고 있는 것이다. 따라서, lock or encrypt만 가능하다.
receiver 서버는 동일한 key가 있기 때문에, 정보를 decrypt가능하다.
그럼 해커는 해킹할 방법이 없을까?
아니다. 있다.
해커가 은행 사이트와 동일한 웹 사이트를 만들고, 유저의 라우팅을 그 사이트로 가도록 우회시킨다.
그리고 public key를 가지고 있으니 유저가 값만 전달하면, 이를 decrypt할 수 있겠다.
그래서, 인증서라는 개념이 나온다.
그런데, 해커도 인증서를 만들 수 있지 않은가?
다행히 대부분의 web brower는 인증서의 validation을 체크할 수 있어서 이를 방지할 수 있다.
그럼, 어떻게 인증된 certificate (legitimate certificate)를 만들 수 있을까?
CA라는 공인된 organization에 CSR(Certificate Signing Request)을 통해 만들 수 있다.
# openssl req -new -key my-bank.key -out my-bank.csr
-subj "/C=US/ST=CA/O=MyOrg, Inc./CN=my-bank.com"
해커의 인증서인 경우, 이는 CA의 Validate check에서 거절당한다.
근데, 또 fake CA를 사용하여 인증서를 만든다면?
괜찮다. 웹 브라우저에는 위 공인된 기관의 Certificate가 이미 등록되어 있기 때문에 fake CA를 가려낼 수 있다.
여기까지는 은행같은, 우리가 방문하는 웹사이트에 대해 확신을 줬다.
그런데, 이들은 pravately 하게 hosted되는 사이트에 대해서는 validate할 수 없다.
예를 들어, 연봉접근이나 내부 이메일을 통한 경우 말이다.
이를 위해 우리는 private CA를 가질 수 있다.
그럼 internal CA 서버를 통해 public key를 가질 수 있고, secure connetivity를 수립할 수 있다.
정리하자면, 위와 같은 1~6 절차를 통해 사이트 접근이 진행된다.
그런데, 서버는 어떻게 client를 validate할까?
위 절차로 진행한다.
그런데, 우리는 website에 접속하기 위해 client 인증서를 만든 적이 없다.
왜냐면, TLS client certificate는 일반적으로 웹서버에서 실행되기 때문이다.
그래서 인증서를 굳이 만들고 관리할 필요가 없다.
즉, ca 및 생성, 인증서를 포함한 모든 절차는 public key 인프라스트럭쳐 or PKI라고 부른다.
네이밍은 위와 같다. PUBLIC는 *.crt, *.pem이고 private key는 *.key가 포함된다.
출처: Udemy 사이트의 Certified Kubernetes Administrator (CKA) with Practice Tests 강의