[Web] HTTP와 HTTPS 그리고 SSL

HTTP vs HTTPS

HTTP(HyperText Transfter Protocol)

• HTML 문서를 전송하기 위한 통신 규약입니다.
• 암호화되지 않은 방법으로 데이터를 전송하기 때문에 서버와 클라이언트가 주고 받는 메시지를 감청하는 것이 매우 쉽습니다.

HTTPS(HyperText Transfter Protocol Secure)

• S = Over Secure Socket Layer
• 보안 장치가 결합되어있는 통신 규약입니다.

HTTPS와 SSL(TLS)

• SSL 프로토콜 위에서 HTTPS가 작동하는 것입니다.
• SSL ≠ HTTPS
• TLS 1.0은 SSL 3.0을 계승한다.
  • 정식 명칭은 TLS이고 역사적인 이유로 SSL이라는 이름을 많이 사용합니다.

SSL(TLS)

SSL 디지털 인증서

• 클라이언트와 웹서버간의 통신을 제3자가 보증해주는 전자화된 문서입니다.
• 클라이언트가 서버에 접속한 직후에 서버는 클라이언트에서 이 인증서 정보를 전달합니다.
• 클라이언트는 이 인증서 정보가 신뢰할 수 있는 것인지를 검증한 후에 다음 절차를 수행하게 됩니다.

SSL 디지털 인증서를 사용했을 때의 이점

• 통신 내용이 공격자에게 노출되는 것을 막을 수 있습니다. (=암호화)
• 클라이언트가 접속하려는 서보가 신뢰할 수 있는 서버인지를 판단할 수 있습니다.
• 통신 내용의 악의적인 변경을 방지할 수 있습니다.

대칭키

대칭키

• 암호화, 복호화할 때 동일한 Key를 사용하는 것

암호화 예제

$ openssl enc -e -des3 -salt -in plaintext.txt -out ciphertext.bin;

• openssl: 암호화(복호화) 프로그램
• enc -e -des3: des3 방식으로 암호화 (대칭키 암호화 기법중 하나)
• -salt: [?]
• -in [filename]: 암호화할 파일
• -out [filename]: 암호화된 파일

복호화 예제:

$ openssl enc -d -des3 -in ciphertext.bin -out plaintext2.txt;

• 복호화하려면 암호화할 때 입력한 password를 입력해야합니다.
• openssl: 암호화(복호화) 프로그램
• enc -d -des3: des3 방식으로 복호화
• -in [filename]: 복호화할 파일
• -out [filename]: 복호화된 파일

공개키

공개키

• 대칭키와 가장 큰 차이점은 key가 2개 존재한다는 것입니다. (pair로 존재)
  • public key와 private key 이며 공개키는 누구든 노출/소유할 수 있습니다.
• public key로 암호화 했다면 반드시 private key로 복호화 해야합니다.
  • private key로 암호화 했다면 반드시 public key로 복호화 해야합니다.
• 일반적인 암호화 기법은 public key로 암호화하여 private key를 소유한 사람에게 전달합니다.

인증

자신이 받은 정보가 올바른 사람이(예상하는 사람이)준 데이터인지 인증하는 것.

• private key를 가지고 있는 사람이 private key로 정보를 암호한 뒤, public key를 갖고 있는 사람에게 정보를 전달합니다.
  • public key는 누구나 갖을 수 있으므로 이는 암호로써 기능이 없습니다.
• 정보를 public key로 복호화 성공 했다면 private key를 가지고 있는 사람이 전송한 정보라는 것이 보증되는 것입니다.
  • 이는 공개키의 정반대의 방법을 활용한 것으로 인증의 원리입니다. => SSL 인증

공개키 예제(1): private key 생성

$ openssl genrsa -out private.pem 1024;

• openssl: 암호화(복호화) 프로그램
• genrsa: rsa 방식으로 암호화 (공개키 암호화 기법중 하나)
• -out [filename]: private key 생성
• 1024: 암호의 복잡도 (높을 수록 안전하지만, 많은 컴퓨팅 파워가 필요)

공개키 예제(2): public key 생성

$ openssl rsa -in private.pem -out public.pem -outform PEM -pubout;

• openssl: 암호화(복호화) 프로그램
• rsa: rsa 방식으로 암호화
• -in [filename]: 공개키 예제(1) 과정에서 만든 private key 이름
• -out [filename]: public key 이름
• -outform PEM -ubout: 생성

공개키 예제(3): 평문 생성

$ echo 'coding everybody' > file.txt

공개키 예제(4): public key로 평문 암호화

$ openssl rsautl -encrypt -inkey public.pem -pubin -in file.txt -out file.ssl;

• rsautl -encrypt -inkey: public key로 암호화
• -pubin -in [filename]: 암호화 대상
• -out [filename]: 암호화된 파일

공개키 예제(5): private key로 평문 복호화

$ openssl rsautl -decrypt -inkey private.pem -in file.ssl -out decrypted.txt

• sautl -decrypt -inkey [filename]: private key로 복호화
• -in [filename]: 복호화 대상
• -out [filename]: 복호화된 파일

SSL 인증서

SSL 인증서의 역할

1. 클라이언트(웹 브라우저)가 접속한 서버가 신뢰할 수 있는 서버임을 보장합니다.
2. SSL 통신에 사용할 public key를 클라이언트에게 제공합니다.

CA(Certificate Authority)

• 인증서의 역할은 클라이언트가 접속한 서버가 클라이언트가 의도한 서버가 맞는지를 보장하는 역할을 하는데,
  이 역할을 하는 민간기업들을 CA(Certificate Authority) 혹은 Root Certificate 라고 부릅니다.

  엄격한 기준에 따라 공인된 기업들만 참여할 수 있습니다. (Symantec, Comodo, GoDaddy 등)

• 브라우저 벤더들의 판단에 따라 CA 기관들의 리스트는 브라우저에 이미 탑재되어 있습니다.

• SSL을 통해 암호화된 통신을 제공하려면 CA를 통해 인증서를 구입해야합니다.

SSL 인증서의 내용

1. 서비스의 정보 (인증서를 발급한 CA, 서비스 도메인 등)
2. 서버측 공개키 (공개키의 내용, 공개키의 암호화 기법)

브라우저는 CA를 알고 있다

• 브라우저는 내부적으로 CA 리스트를 알고있습니다.

  즉, 브라우저의 소스코드 안에 CA의 리스트가 들어있다는 것

• 브라우저의 CA 리스트에 포함되어야만 공인된 CA가 될 수 있습니다.
• 브라우저는 CA 리스트와 함께 각 CA의 public key를 브라우저는 이미 알고 있습니다.

SSL 인증서가 서비스를 보장하는 방법

1. 웹 브라우저가 서버에 접속할 때 서버는 제일 먼저 인증서를 제공합니다.
2. 브라우저는 서버가 제공한 인증서를 자신이 가지고있는 CA 리스트에 있는지 확인합니다.
3. CA 리스트에 포함되어있다면 해당 CA의 public key를 이용하여 인증서를 복호화합니다.

   비밀키로 암호화한 정보를 공개키로 복호화할 수 있다는 것은 정보가 비공개로 암호화되었다는 것을 뜻합니다.

위 과정이 CA와 브라우저가 특정 서버를 인증하는 과정입니다.

SSL의 동작방법

• 실제 데이터: 대칭키로 암호화 (컴퓨팅 파워가 적게 든다)
• 대칭키의 키: 공개키로 암호화

컴퓨터와 컴퓨터가 네트워크를 이용해서 통신할 때는 내부적으로 3가지 단계가 있습니다.

악수 -> 전송 -> 세션종료

악수

1. Client hello: 클라이언트가 서버에 접속합니다.

   • 클라이언트측에서 생성한 랜덤 데이터
   • 클라이언트가 지원하는 암호화 방식들
     - 클라이언트가 해석[처리]할 수 있는 암호화 리스트
   • 세션 아이디

2. Sever hello: 서버가 Client Hello에 대한 응답합니다.

   • 서버측에서 생성한 랜덤 데이터
   • 서버가 선택한 클라이언트의 암호화 방식
     - 서버도 처리할 수 있으면서 안전한 암호화 기법을 선택후 클라이언트에게 전달
     - 클라이언트와 서버가 어떤 암호화 기법을 사용할지 협상하는 과정
   • 인증서

3. 클라이언트는 서버가 전송한 인증서가 어떤 CA에 의해 발급된 것인지 확인 후 브라우저에 내장되어있는 CA인지 확인합니다. 만약, 브라우저의 CA 리스트에 있다면 브라우저는 자신이 가지고 있는 해당 인증 기관의 public key로 인증서를 복호화를 시도합니다. 이때 public key로 복호화되었다면 이 인증서는 해당 인증기관에 의해 발급된 인증서라는 것을 보증하게됩니다. 즉, 자신이 접속한 서버가 인증 기관에의해 보증된 서비스라는 것을 확실할 수 있게된 것입니다.
   
   그리고 인증서에는 서버가 생성한 public key가 들어있는데 클라이언트는 해당 인증서의 public key를 획득하게 됩니다. 서버는 public key에 해당하는 private key를 가지고있으며 서버는 private key가 절대 노출되어서는 안됩니다. 클라이언트는 서버측에서 생성한 랜덤 데이터와 자신이 생성한 랜덤 데이터를 조합후 서버가 전송한 public key로 암호화하여 pre master secert 키를 생성후 서버로 전송합니다.

4. 서버는 클라이언트가 전송한 pre master secret 값을 서버의 private key로 복호화합니다. 이로써 서버와 클라이언트 모두 pre master secert 값을 공유하게 됩니다. 그리고 서버와 클라이언트는 모두 일련의 과정을 거쳐서 pre master secert 값을 master seceret 값으로 만듭니다. master secert는 session key를 생성하는데 session key 값을 이용해서 서버와 클라이언트는 data를 대칭키 방식으로 암호화한 후에 주고받습니다. sessions key를 클라이언트와 서버 모두 공유하게 되었다는 점을 기억해야 합니다.

5. 클라이언트와 서버는 악수 단계의 종료를 서로에게 알립니다.

세션

• 세션은 실제로 서버와 클라이언트가 data를 주고받는 단계입니다. 이 단계의 핵심은 상대방에게 data를 전송하기 전에 session key 값을 이용해서 대칭키 방식으로 암호화한다는 것입니다. 암호화된 data는 상대방에게 전송될 것이고, 상대방도 session key 값을 알고 있기 때문에 data를 복호화 할 수 있다.

세션종료

• 데이터의 전송이 끝나면 SSL 통신이 끝났음을 서로에게 알려준다. 이때 통신에서 사용한 대칭키인 세션키를 폐기합니다.

[참고]
https://opentutorials.org/course/228/4894