SSL 동작 방식

대칭키

동일한 키로 암호화와 복호화를 같이 할 수 있는 방식의 암호화 기법

 

단점 : 암호화된 텍스트 + 대칭키를 같이 전송해야 되는데, 대칭키를 누군가 가져가면 암호화된 텍스트가 아무런 쓸모가 없어진다. 이를 해결하기 위해서는 비대칭키(공개키)를 사용한다.

 

비대칭키(공개키)

암호화 방식은 비밀키와 공개키를 통해 암호화하는 방식이다.

 

공개키로 암호화한것은 오직 비밀키로 복호화가 가능하다.(그 반대도 가능)

비밀키는 오직 자신만이 가지고 있고, 공개키는 누구나 가질 수 있도록 한다. 그리고 누군가 나에게 암호화된 데이터를 전송하고 싶을 땐 공개키를 통해 암호화해서 전송한다. 암호화된 정보는 오직 내가 가지고 있는 비밀키로만 복화가 가능하기 때문에 안전하다.

 

 

• SSL
• SSL 인증은 SSL 인증서( 신분증 같은 개념 )가 있는 웹 사이트만 실행할 수 있다.
• 그리고 이 SSL 인증서는 가장 중요한 정보에 공개 키라는 걸 포함하는데, 공개 키를 이용해서 클라이언트와 웹 서버가 안전하게 암호화가 가능하다.
• 클라이언트는 공개 키를 보고 공개키를 이용해서 웹 서버와 안전하게
  암호화 키를 수립한다.
• 또, 웹 서버에는 기밀로 유지되는 개인 키가 있다. 이 개인 키는 공개키로 암호화된 데이터를 해독할 때 사용한다.

 

 

SSL 인증서의 내용

• 서버의 정보(인증서를 발급한 CA, 서버 도메인)
  서버 측 공개키
• CA의 공개키(비밀키)로 SSL 인증서 내용을 암호화한 전자서명 ( CA를 브라우저는 알고 있다.)

 

SSL 인증서가 서버를 보증하는 방법

• 웹 브라우저가 서버에 접속할 때 서버는 제일 먼저 SSL 인증서를 제공한다. ( SSL 인증서는 암호화되지 않음, 하지만 SSL 인증서안에는 SSL 인증서 내용을 CA의 비공개키로 암호화한 전자서명이 들어있다. )
• 브라우저는 SSL 인증서를 보고, 인증서를 발급한 CA가 자신이 내장한 CA 리스트에 있는지 확인한다
• CA 리스트에 포함되어 있다면
• CA 공개키를 이용해서 전자서명을 복호화한다
• CA의 공개키를 이용해서 전자서명을 복호화할 수 있다는 것은 이 인증서가 CA의 비공개키에 의해서 암호화된 것을 의미한다.
• 이것은 결국 CA에서 보증하는 신뢰할 수 있는 서버라는 뜻이다.

 

 

SSL의 동작 방법 ( 대칭키 + 비대칭키 )

HandShke

1. 클라이언트가 서버에 접속한다.

• request 내용
  • 클라이언트 측에 생성한 랜덤 데이터 → 111
  • 클라이언트가 지원하는 암호화 방식들
  • 세션 아이디 → 이미 SSL 핸드쉐이킹을 했다면 비용과 시간을 절약하기 위해서 기존의 세션을 재활용하게 되는데, 이때 사용할 연결에 대한 식별자를 서버 측으로 전송
    서버가 클라이언트에게 응답한다 
• response 내용
  • 서버 측에서 생선 한 랜덤 데이터 → 333
  • 서버가 선택한 클라이언트의 암호화 방식
  • SSL 인증서(공개키도 들어있음)
    
    

1. 클라이언트는 서버의 SSL 인증서가 CA에 의해 발급된 것인지, CA리스트를 통해 확인한다.

 

2. SSL 인증서가 CA에 의해서 발급된 것을 확인하기 위해서, 클라이언트에 내장된 CA 공개키를 통해서 SSL 인증서에 들어있는 전자서명을 복호화한다.

 

3. 전자서명의 복호화에 성공했다면, CA의 개인키로 암호화된 문서임을 보증한다는 뜨이다. 즉 인증서를 전송한 서버를 믿을 수 있게 된다.

 

4. 클라이언트는 서버를 통해 받은 서버의 랜덤 데이터 333과 클라이언트가 생성한 랜덤 데이터 1111을 조합해서 인증서에 포함된 서버의 공개키로 암호화한다.(대칭키로 한다) 그리고 해당 데이터(대칭키)를 전송한다.

 

5. 서버는 클라리언트가 모두 대칭키를 자신의 비밀키로 복호화한다.

 

6. 이로서 서버와 클라이언트가 모두 대칭키를 안전하게 공유할 수 있게 된다.

 

7. 이로써 서버와 클라이언트는 데이터를 대칭키 방식으로 암호화한 후에 주고받는다

 

8. 클라이언트와 서버는 핸드쉐이크 단계의 종료를 서로에게 알린다

• 세션
  • 실제로 서버와 클라이언트가 데이터를 주고받는 단계
• 세션 종료
  • 데이터의 전송이 끝나면 SSL 통신이 끝났음을 서로에게 알려준다. 이때 통신에서 사용한 대칭키를 폐기한다

 

 

총 정리 

----------------------------------------------------------------------------------------------------------

대칭키 

동일한 키로 암호화와 복호화를 같이 할 수 있는 방식의 암호화 기법

 

단점 : 암호화된 텍스트 + 대칭키를 같이 전송해야 되는데, 대칭키를 누군가가 가져가면 암호화된 텍스트가 아무런 쓸모가 없어진다. 이를 해결하기 위해서 비대칭키가 있다.

 

비대칭키(공개키)

비대칭키 암호화 방식은 비밀키와 공개키를 통해 암호화하는 방식이다. 공개키로 암호화한 것은 오직 비밀키로 복호화 가능하다. ( 그 반대도 가능)

 

비밀키는 오직 자신만이 가지고 있고, 공개키는 누구나 가질 수 있도록 한다. 그리고 누군가 나에게 암호화된 데이터를 전송하고 싶을 땐 공개키를 통해 암호화해서 전송한다. 암호화된 정보는 오직  내가 가지고 있는 데이터를 전송하고 싶을땐 공개키를 통해 암호화해서 전송한다. 암호화된 정보는 오직 내가 가지고 있는 비밀키로만 복호화가 가능하기 때문에 안전하다.

 

======정보보안 =====

공개키 방식은 전자서명에도 이용된다.

• 비밀키로 암호화한 데이터를 공개키와 함께 전송한다.
• 엥? 공개키가 노출되면 복호화가 가능한데?
• 정보의 보안의 목표가 아님.
• 비밀키로 암호화된 정보 + 공개키가 있다는 의미는?
• 데이터를 제공한 사람의 신원을 보장한다
• 이것이 바로 전자서명이다.

하지만 이 비대칭 키는 컴퓨팅 자원이 많이 든다.

 

 

SSL의 동작 방법 ( 대칭키 + 비대칭키 )

HandShke

1. 클라이언트가 서버에 접속한다.

• request 내용
  • 클라이언트 측에 생성한 랜덤 데이터 → 111
  • 클라이언트가 지원하는 암호화 방식들
  • 세션 아이디 → 이미 SSL 핸드쉐이킹을 했다면 비용과 시간을 절약하기 위해서 기존의 세션을 재활용하게 되는데, 이때 사용할 연결에 대한 식별자를 서버 측으로 전송
    서버가 클라이언트에게 응답한다 
• response 내용
  • 서버 측에서 생선 한 랜덤 데이터 → 333
  • 서버가 선택한 클라이언트의 암호화 방식
  • SSL 인증서(공개키도 들어있음)
    
    

1. 클라이언트는 서버의 SSL 인증서가 CA에 의해 발급된 것인지, CA리스트를 통해 확인한다.

 

2. SSL 인증서가 CA에 의해서 발급된 것을 확인하기 위해서, 클라이언트에 내장된 CA 공개키를 통해서 SSL 인증서에 들어있는 전자서명을 복호화한다.

 

3. 전자서명의 복호화에 성공했다면, CA의 개인키로 암호화된 문서임을 보증한다는 뜻이다. 즉 인증서를 전송한 서버를 믿을 수 있게 된다.

 

4. 클라이언트는 서버를 통해 받은 서버의 랜덤 데이터 333과 클라이언트가 생성한 랜덤 데이터 1111을 조합해서 인증서에 포함된 서버의 공개키로 암호화한다.(대칭키로 한다) 그리고 해당 데이터(대칭키)를 전송한다.

 

5. 서버는 클라리언트가 모두 대칭키를 자신의 비밀키로 복호화한다.

 

6. 이로써 서버와 클라이언트가 모두 대칭키를 안전하게 공유할 수 있게 된다.

 

7. 이로써 서버와 클라이언트는 데이터를 대칭키 방식으로 암호화한 후에 주고받는다

 

8. 클라이언트와 서버는 핸드쉐이크 단계의 종료를 서로에게 알린다

• 세션
  • 실제로 서버와 클라이언트가 데이터를 주고받는 단계
• 세션 종료
  • 데이터의 전송이 끝나면 SSL 통신이 끝났음을 서로에게 알려준다. 이때 통신에서 사용한 대칭키를 폐기한다