정보 보호) SSL, HTTP, HTTPS

SSL(Secure Socket Layer) : 보안 소켓 계층

서버-서버 또는 서버-클라이언트 사이에 전송되는 데이터를 암호화하여 인터넷 연결을 보호하기 위한 표준 기술 

TLS(Transport Layer Secure Protocol)
TLS 네스케이프에 의해서 SSL이 발명되었고, 이것이 점차 폭넓게 사용되다가 표준화 기구인 IETF의 관리로 변경되면서 TLS라는 이름으로 바뀌었습니다. TLS 1.0은 SSL 3.0을 계승합니다. 하지만 TLS라는 이름보다 SSL이라는 이름이 훨씬 많이 사용되고 있습니다.
출처: https://12bme.tistory.com/80 [길은 가면, 뒤에 있다.:티스토리]

 

HTTP (HyperText Transfer Protocol) 와 HTTPS (HyperText Transfer Protocol Secure)

HTTP는 HTML(=HyperText)를 전송하기 위한 통신 규약

HTTPS는 SSL 프로토콜 상에서 돌아가는 HTTP로 SSL/TLS 인증서로 웹사이트를 보호하는 경우 HTTP를 안전하게 암호화하여 전달할 수 있다. 즉, SSL 인증서 기반의 HTTP == HTTPS

 

암호화 기법

1. 대칭키 : 동일한 키로 암호화와 복호화를 모두 할 수 있는 기법
   • 암호를 주고 받는 사람들 사이에 키 전달이 어렵다.
   • 키가 유출되면 복호화가 쉽다. -> 안전하지 않음 -> 비대칭 방식 등장 
2. 공개키 (비대칭방식) : 자신만이 가지고 있는 비공개키와 상대방이 가지고 있는 공개키, 두가지를 이용해 암호화하는 방식
   • 암호화와 복호화에 사용하는 키가 서로 다르다. 
   • public key로 정보를 암호화하면 이 정보는 private key로만 복호화할 수 있습니다. 
   • 따라서 public key가 있다고 해서 private key가 없으면 복호화가 불가능하다.  
   • public key가 데이터를 제공한 사람의 신원을 보장한다. == 전자 서명
   • 단점은 계산이 좀 느리다는 것.
   • RSA 방식 : 
     1. n-bit의 private key를 생성한다. 
     2. private key와 쌍을 이루는 public key를 생성한다. 
     3. public key를 정보를 제공할 사람에게 전달한다. 
     4. Public key를 받은 사람은 해당 정보를 제공하는 사람(=private key를 가지고 있는 사람)에게 public key를 보여주면 데이터 안전하게 전달! 

 

SSL 디지털 인증서  

SSL 인증서는 클라이언트와 서버간 통신을 제 3자가 보증해주는 전자화된 문서 

출처 : https://12bme.tistory.com/80

SSL 인증서의 역할

• 클라이언트가 접속한 서버가 신뢰할 수 있는 서버임을 보장한다.
• SSL 통신에 사용할 공개키를 클라이언트에게 제공한다. 
• 장점
  • 통신 내용이 공격자에게 노출되는 것을 방지한다.
  • 클라이언트가 접속하려는 서버가 신뢰할 수 있는 서버인지 판단할 수 있다. 
  • 통신 내용의 악의적 변경을 방지할 수 있다. 

Certificate Authority (CA)

• SSL인증서를 발급해주는 기관 
• CA는 CA의 public key로 SSL 인증서를 구매하고자 하는 서버 정보를 암호화한다.  
• 브라우저는 내부적으로 CA 리스트를 미리 파악하고 있으며, 이 리스트에 포함된 CA만이 공인된 CA이다. 
• 브라우저는 각 CA의 공개키도 알고 있다. 

SSL 인증서의 내용

서비으 도메인, 공개키 정보는 서버가 CA로부터 SSL 인증서를 구입할 때 제출해야 한다. 

• 서비스 정보 
  • 인증서 발급한 CA 정보 
  • 서비스 도메인 등
• 서버 측 공개키 => 전자 서명 (신원을 보장함) 
  • 공개키 내용
  • 공개키 암호화 기법 

SSL 인증서 동작 방식

1. 클라이언트 (브라우저)가 서버에 접속한다.
2. 서버는 접속한 클라이언트에게 SSL 인증서를 제공한다. 
3. 클라이언트는 이 인증서를 발급한 CA가 자신이 파악하고 있는 CA리스트에 있는지 확인한다. 
4. 공인된 CA라는 것이 확인되면 해당 CA의 public key를 이용해서 인증서를 복호화한다. 
5. CA의 public key로 SSL 인증서 복호화에 성공했다는 것은 해당 인증서가 CA의 비밀키에 의해 암호화된 것임을 인증한다. 
6. 이 검토를 통과하면 해당 서버가 신뢰할 수 있다는 것을 의미한다. 

SSL이 암호화된 데이터를 전송하기 위해 사용하는 방법

• 비대칭키 = 컴퓨터 자원 낭비 큼 
• 대칭키 = 안전성이 떨어짐 
•  => 공개키 + 대칭키 혼합 방식 사용 

1. Client Hello : 클라이언트가 서버에 접속  
   • 클라이언트가 자신이 사용할 수 있는 암호화방식을 전달 
   • 이미 SSL 검증을 한적이 있다면 기존 세션을 재활용하기 위해 세션 아이디를 식별자로 사용
2. Server Hello : 서버가 접속한 클라이언트에 응답 
   • 서버도 자신이 사용할 수 있는 암호화 방식을 선택해서 클라이언트로 전달 -> 암호화 방식에 대한 협상 종료 
   • 협상된 암호화 방식으로 정보 교환 ! 
3. 클라이언트가 서버에서 전달해준 SSL 인증서 신뢰성 검증
   • 클라이언트 내장 CA 리스트에서 찾아보고 없다면 사용자에게 경고! 
   • 있다면 CA의 공개키를 이용해서 인증서 복호화 
   • 복호화 성공 == CA의 개인키로 암호화된 문서임이 보증 -> 서버 신뢰
4. 클라이언트는 클라이언트와 서버가 서로 hello 단계에서 주고받은 랜덤 데이터를 조합해서 pre master secret 키를 생성한다. 이 키는 대칭키 방식이기 때문에 이 키로 복호화와 암호화가 모두 이루어진다. 따라서 절대! 노출되어서는 안되는 키이다. 
5. 클라이언트는 pre master secret키를 서버의 공개키로 암호화해서 서버로 전송한다. 서버의 공개키는 서버가 전달해준 SSL 인증서에 들어있다. 
6. 서버는 클라이언트로부터 받은 암호화된 pre master secret 키를 자신의 private key로 복호화한다. 이로써 서버와 클라이언트가 안전하게 pre master secret 키를 주고받았고, 서버와 클라이언트는 pre master secret 키를 master secret 값으로 바꾼다. 
7. master secret은 세션키를 생성하는데 세션키 값을 이용해서 서버와 클라이언트가 데이터를 대칭키 방식으로 암호화한 후 주고 받을 수 있게 한다. 
8. 핸드쉐이크 단계의 종료 -> 클라이언트와 서버가 서로에게 종료 통지 
9. 세션 : 실제 서버와 클라이언트가 데이터를 주고 받는 단계 
   • 세션 키 값을 이용해서 대칭키 방식으로 주고받을 데이터를 암호화 
   • 서버와 클라이언트는 위 과정을 통해 모두 동일한 세션키를 가지고 있다. 이 세션키로 암호화해서 전달하면 상대 측에서 같은 세션키로 복호화해서 데이터에 접근할 수 있다. 

즉, SSL 인증서를 통한 보안 검증 과정은 속도는 느리지만 데이터를 안전하게 주고받을 수 있는 비대칭키(public-private key)방식으로 대칭키를 암호화하고, 실제 데이터를 주고받을 때에는 그 대칭키를 사용한다. 

데이터 전송 종료 후에는 SSL 통신이 종료되었음을 서로에게 알리고 사용한 세션키를 폐기한다. 

 

 

 

 

 

---

References

• https://www.digicert.com/kr/what-is-ssl-tls-and-https
• https://12bme.tistory.com/80