들짐승 프로그래밍

RSA, SSL, HTTPS에 대한 사전지식이 필요하다.

https://fieldanimal.tistory.com/79?category=908294 

SSL 인증서가 필요한 이유

위 글에서 public key 자체가 잘못된 public key면 내 개인정보를 털릴 수 있다고 했다.

지금 나는 Tistory로부터 public key를 받아서 안심하고 통신을 시작하는데 근본부터 속았다면,,

그럼 public key가 Tistory로부터 받았다는걸 어떻게 증명하냐? 제3기관의 힘을 빌린다. 이들은 믿을만하다는 것이다.

실제로 크롬, 웨일 등 브라우저를 설치하면 자동으로 많은 인증서들이 등록되어있다.

대략적인 과정

클라이언트는 서버로부터 인증서를 받고

인증서에 적혀있는 발급자 서명을 이용해 해당 인증서가 발급자로부터 검증받은 것임을 확인한다.

발급자가 위 리스트에 들어있으면 OK이고 통신을 시작한다.

SSL handshake과정중 certificate 과정이다.

https://aws-hyoh.tistory.com/entry/HTTPS-%ED%86%B5%EC%8B%A0%EA%B3%BC%EC%A0%95-%EC%89%BD%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-3SSL-Handshake

<ssl handshake과정>

OpenSSL

OpenSSL이란, TLS 인증서를 만들기 위한 과정을 대신해주는 오픈소스 라이브러리이다.
인증서를 만드려면 private key도 만들고 csr도 만들고 cert도 발급하고 기타 등등을 해야하는데 사용할 알고리즘, 파라미터를 입력해주면 파일로 만들어준다.

아무리 프로토콜이 정해져있다고 해도 우리가 직접 코딩하고 계산해서 만들 수는 없기 때문에 이런 라이브러리를 이용해야한다.

https://aspdotnet.tistory.com/2653

<OpenSSL 설치>

예시로 과정 살펴보기

https://www.lesstif.com/system-admin/openssl-root-ca-ssl-6979614.html

<OpenSSL CLI를 이용한 인증서 발급 과정>

MyCompany : 서버 이름

COMODO : 브라우저에 내장된 신뢰할 수 있는 CA 이름 예시

0. MyCompany의 private key를 만든다.

1. CSR 생성

mycompany 인증서를 위한 CSR를 만든다. CSR은 인증서 발급 요청서 양식이다.
이때 mycompany 도메인, 지역 등의 정보를 기입한다.

2. 인증서 발급

COMODO에게 CSR을 넘겨주고 인증서를 발급받는다.

https://comodosslstore.com/promoads/ssl-certificates.aspx?gclid=CjwKCAjw3cSSBhBGEiwAVII0Z1YlKGMSf60MyriJkTyIIIQn0VYe9TQ0TQHMWy38JbWJ4mnzybWTzxoC5oIQAvD_BwE

<실제 인증기관, https 서버를 정식으로 운용하고싶으면 돈을 내고 인증서를 받을 수 있다.>

인증서 안에는 MyCompany의 도메인, MyCompany의 public key, 발급자(COMODO) 등등의 정보들과 지문이 들어있다. 

지문은 MyCompany의 public key를 COMODO의 private key로 암호화한 서명이다. 실제로는 실제로는 정보들의 해시값을 암호화하지만 이해를 쉽게 하기 위해 public key를 암호화한다고 단순화해서 생각해본다.

https://chickenpaella.tistory.com/40​

3. 클라이언트에게 인증서 전달

요청이 들어온 클라이언트한테 COMODO에서 발급받은 인증서를 던져준다. 이때 클라이언트는 수신한 인증서가 MyCompany가 맞는지 계속 의심을 하고있는 상태이다.

4. 인증서 검증

COMODO는 브라우저가 이미 신뢰하고있는 인증서이다.

COMODO의 Public Key를 이용해 MyCompany 인증서의 지문을 복호화한다.
이때 MyCompany 인증서의 Public Key와 복호화해서 나온 Public Key가 동일하면, MyCompany는 COMODO에게 인증을 받았다는게 확실하고, COMODO는 브라우저가 신뢰하고 있는 기관이므로 MyCompany도 신뢰할 수 있게 된다. 브라우저에는 깔끔한 자물쇠가 뜬다.

5. 인증서 chain

만약에 COMODO가 Root CA가 아닌 중간기관이면 COMODO의 Public Key 또한 믿을 수 없으므로

COMODO 인증서에 적힌 Public Key와

COMODO 인증서의 지문을 발급자(Root CA)의 Public Key로 복호화해서 나온 값을 비교한다.

타고 타고 타고 올라가서 결국 Root CA한테 받은게 맞으면 정말 OK이다.

Root CA란?

https://m.blog.naver.com/alice_k106/221468341565

모든 흐름을 자세하게 설명해놓으신 형님의 글을 보면 된다.

CA Chain을 계속 하다보면 언젠간 꼭대기까지 올라가게되는데 이를 Root CA라고 부른다.

Root CA는 더이상 올라갈 곳이 없기 때문에 지문(서명)을 다른 기관이 아닌 자신의 Private Key로 만든다.
브라우저가 믿을 수 있는 절대 안뚫리는 곳이라고 한다.

사설 인증서 생성

테스트용으로 Root CA를 만들고 그 Root CA로부터 인증서를 발급받아서 서버를 구축해본다.

1. Root CA private key를 만든다.
2. Root CA csr를 만든다(인증서 요청서)
3. Root CA의 인증서를 만든다(crt) : Root가 Root에게 셀프로 발급

4. 서버용 private key 생성

5. csr 생성 후 Root CA로부터 인증서 발급

Root CA를 직접만들어서 Root CA로부터 지문을 받은 인증서는, 브라우저에서 신뢰할수없다고 뜬다.
이유는 브라우저에 등록된 인증서에 당연히 내가 셀프로 만든 인증서가 없기 때문이다.

KeyStore

직접 OpenSSL 명령을 입력해가며 테스트해보니 많은 파일들이 생겼다.

확장자별 의미 : https://www.ihee.com/616

keystore를 이용해서 널부러져있는 파일들을 지갑처럼 한데모아 사용할 수 있다. 

https://dimdim.tistory.com/entry/openssl%EC%9D%84-%EC%9D%B4%EC%9A%A9%ED%95%9C-Tomcat-HTTPS-%EC%84%A4%EC%A0%95-PKCS12-%ED%8F%AC%EB%A7%B7

openssl로 .p12 확장명 keystore를 만들 수 있고

openssl과 비슷한 java keytool로 .jks 확장명 keystore를 만들 수도 있고

둘을 변환하며 쓸 수 있다.

변환 가이드 : https://www.sslcert.co.kr/guides/SSL-Certificate-Convert-Format

https://100100e.tistory.com/317

이분이 그림도 그려놓고 아주 잘 설명해놓으셨다.

대칭키 방식

• A<->B 통신시 암호화를 위해 대칭키를 사용할 수 있다.
• 암호화, 복호화에 필요한 키가 동일하여 대칭키라 불린다.
• 암호화하여서 보낸 패킷을 중간에 가로채도 알아볼수없다.
• 하지만 키 자체가 한번은 통신으로 이동해야 하기 때문에 그중에 탈취되면 원본을 알아볼수 있게 된다.
• AES256

비대칭키 방식

• 서버에서 public key, private key를 발급한다. 둘은 소수를 이용해서 어쩌고 만든다.
• private key는 암호화, public key는 복호화에 사용된다.
• 클라이언트에게 public key를 건네준다.
• 서버에 데이터(ex. 로그인 중 password)를 전송시 public key를 이용해 암호화하여 송신한다.
• 제3자가 public key를 탈취했다하더라도 복호화에 사용할 수 없으므로 원본 password는 알아낼수없다.
• 서버에선 전송받은 데이터를 private key를 이용해 복호화한다. (ex. password 원본으로 변경하여 DB에서 조회한다)
• 대칭키 방식에 비해 암,복호화 속도가 느리다.
• RSA

인증서

• public key를 내가 정말 Request를 보내고자하는 서버로부터 발급받으면 상관없지만
  3자가 서버인척하고 private key, public key를 발급후 public key를 내주면 그걸로 암호화한 데이터를 3자에게 보내게 되고 3자는 private key를 이용해 복호화하여 원본데이터를 알아낼 수 있다. (password)
• 강력한 RSA를 이용해서 암호화한 데이터를 보냈다고 방심하지만 결국 public key 자체부터가 썩은 것이다.
• 이를 방지하고자 서버는 CA기관에 public key를 위탁하고 클라이언트는 CA로부터 public key를 받게된다.
• 내가 집에서 만든 서버로 RSA를 구현해서 클라이언트에게 전달해준다면 그건 곧 사설인증서가 되는거고
  클라이언트쪽에선 브라우저에 warning이라는 문구가 뜨면서 신뢰할 수 없는데 괜찮겠냐는 메시지가 뜬다.

TLS

• 비대칭키 방식을 이용해서 쭉 모든 통신을 하면 좋겠지만 암,복호화 속도가 대칭키에 비해 낮다.
  그 한계를 어떻게 극복하냐면
• public key를 받은 후 클라이언트는 대칭key를 서버에 암호화하여 전송한다. (세션키 라고불린다)
• 서버는 private key를 이용해 클라이언트로부터 전달받은 대칭key를 복호화하여 저장한다.
• 이제 대칭키를 서로 알게되었으니 패킷을 대칭key를 이용해 암호화 통신한다.
  대칭키 방식의 취약점이 키가 탈취되면 끝장난다는 것인데
  처음에 public key로 암호화하여 전송하였으니 제3자가 알아낼 수가 없다.
• 이렇게 비대칭키 방식+대칭키 방식을 장점을 버무려서 사용하는 방식이 TLS이고 SSL이라고도 불린다.

HTTPS

• 기존 HTTP는 패킷이 암호화되어있지 않기 때문에 wireshark같은 툴로도 훔쳐서 안의 내용을 보기가 쉽다.
• TLS 보안방식을 적용시켜서 HTTP 패킷 자체를 암호화하면 HTTPS라고 불리는 것이다.
• 제대로된 HTTPS 통신 서버를 만드려면 CA기관에 돈주고 public key를 줘야하기도 하고
  패킷을 받을 때마다 복호화해야하기 때문에 비용이 든다.
• 사용자 password같은 민감한 정보를 제외하고 나머지 내용은 까봐도 별 의미없다고 생각되면 그냥 HTTP 통신을 사용하고, 그 패킷 안의 일부 민감한 정보만 RSA를 이용해 암,복호화 할 수 있다.
• 별 의미없다고 생각되는 내용일지라도 패킷이 훤히 들여다보인다면 고수에게 기가 막힌 방식으로 서버가 공격받을 수 있다. 괜히 HTTPS를 사용하는게 아니다.

HASH

• Hash Function을 이용한 단방향 암호화 방식이다.
• 보통 통신에 사용되는 암호화 방식은 주는 사람이 암호화하고 , 받는 사람이 복호화할 수 있어야 하는데 얘는 한번 암호화하면 끝이다.
• 하지만 얘도 쓸 데가 있다.
• 서버는 사용자의 정보 (ex. password)를 DB에 저장한다.
• 백날 대칭키 비대칭키 이용해서 데이터를 훔쳐보지 못하게 하지만 DB에서 원본 데이터가 털려버린다면 끝이다.
• 따라서 서버에선 복호화한 데이터(password)를 그대로 DB에 저장하고 비교하면 안된다.
• 이때 Hash를 사용해서 password를 암호화하고 DB에 저장한다.
  서버 : password -> DB : 요상한값
• 저장할 때(회원가입) 사용한 Hash Function이랑 조회할 때(로그인) 사용한 Hash Function만 같으면 된다.
• 가끔 Hash Function이 내뱉는 암호화된 값이 중복된다는 문제가 있다고 한다. 이 말은 곧 정확한 password말고 다른 값들로 로그인을 할 수도 있고, 정확히 password를 입력했으나 로그인이 실패할수 있다는 말이 된다.
• 이를 방지하기 위해 Hash Function으로 나온 값에 Salt값을 또 더해서 다시 Hash Function에 넣고 이중으로 처리하는 방식이 있다.
• 소금을 친다.

[리소스 접근, 기능 사용]

사용자가 앱에서 페이스북, 카카오 등의 3p에 로그인 후

access_token을 발급받아서 3p 리소스에 접근하거나 기능을 사용하는 것

게시물 조회, 카카오톡 발송 등

[회원가입]

access_token으로 받은 고유 id를 이용해서 내 서버에 가입시키는 것

1. 3p에 로그인 한다. (카카오로 로그인, 네이버로 로그인 등)

2. 발급받은 Access token을 이용해 고유 id를 갖고온다. (email address)
보통 user/me URL에 요청한다.

3. 고유 id가 내 서버 DB에 있는지 조회한다.

4. 더 갖고오고싶은 정보(nickname)를 입력받아서 user_id와 함께 DB에 집어넣고 회원가입시킨다.
이때 아이디, 비밀번호를 적지 않아도 돼서 편리하다.

5. 추후 로그인시 또 리턴받은 고유id가 DB에 있으면 바로 로그인시킨다. (세션생성, JWT 토큰 발급 등)

기존 세션처럼 사용자 인증정보를 서버 메모리에 저장하지 않고

토큰에 인증 정보를 암호화시켜 포함하도록 한 인증방식