 책 보다보니 갑1088;기 Ƽ17;금해서 1656;문남깁니다. 
1. 대칭Ȗ12; 생성 알고리1608;1004;/196; 나온,148; 디6140;헬먼 0150;에 없lj16;데, 우리가 https 통신할ǐ12; 브라우1200;가 디6140;헬먼 1060;용해서 대칭Ȗ12;를 만든다1020;에특1221;dz12;1060;트1032; 공개Ȗ12;와 ǹ16;호화 알고리1608;(AES, DES መ1;)1012; 1060;용해서 보내lj16;,148;가요? Ȗ12; 교환.104;lj16; 과1221;1060; 1060;해.104;lj16;데, Ȗ12;가 Ǻ12;디서 만들Ǻ12;1648;lj16; Ƽ17;금합니다. 브라우1200;가 만드lj16;,148;1648; 아니면 컴터에 내1109;.108; 특1221; 프/196;그ǖ16;1060; 만드lj16;,148;1648;.. 
2. 디6140;헬먼 같1008; ᅆ1;우 공개Ȗ12; 알고리1608;1012; Ǹ16;1648;만 그안에서 대칭Ȗ12;도 만들Ǻ12;1256;서 상관없lj16;데, 만약 RSA 0169;식1012; 쓴다면 대칭Ȗ12;lj16; 누가 만들lj16;,148;가요? 따/196; 프/196;그ǖ16;1060; 1316;1116;Ȣ16;lj16;,148;1648;...마1648;ኔ1;1004;/196; 헷갈리lj16;,148; AES DES 같1008; ǹ16;호화 알고리1608;1008; Ȗ12; 생성과lj16; 아무런 관/144;1060; 없lj16;,144;1424;?? 생성.108; Ȗ12;/196; ǹ16;호화Ȣ16;lj16; 0169;식1068;1104;.. 1228;가 1228;대/196; 1060;해한,148;1648; 모르,192;네요. 꽤 많1060; 찾아봤lj16;데, 찾아볼수/197; 약간씩 헷갈/140;서요. 
1312;Ǻ16; 1328; ǥ12;ᓠ1;드립니다. 
RSA나 ECDHE같은 비대칭키 알고리즘(대칭키를 서로 교환하기 위한 알고리즘)은 CPU 자원 소모가 대칭키 알고리즘보다 많기 때문에,
서버-클라이언트 간 데이터(HTML 등)은 대칭키(AES)로 암호화합니다. (AES 같은 경우는 CPU 가속도 되고요.)
그러나 대칭키는 한번 노출되면 제3자(해커)가 도청할 수 있으므로 매번 새로 만들어 사용합니다.
대칭키(데이터 전송에 사용할 master secret)를 만드는 방법은 Client Nonce, Server Nonce, PMS의 조합으로 만드는데, (셋 다 랜덤입니다.)
Client Nonce와 PMS(Pre-Master Secret)는 클라이언트 브라우저에서 만들고, Server Nonce는 웹서버에서 만듭니다.
Client Nonce는 Client Hello에서, Server Nonce는 Server Hello 과정에서 서로에게 평문으로 전달됩니다.
클라이언트는 Server Hello때 서버에서 보낸 TLS 인증서를 받는데, 이 인증서로 Pre-Master Secret를 암호화(비대칭키)해서 서버로 넘깁니다.
Nonce는 재전송 공격을 막는 용도이고, 실질적인 대칭키 알고리즘의 키가 되는 것은 PMS라고 보면 됩니다.
제가 보는 책 일부분을 캡쳐했습니다.
https://d.pr/i/2P5xsH
디피-헬먼은 키 교환 알고리즘인데, HTTPS(TLS) 환경에서는 대칭키에 DH 파라미터가 들어가기 때문에 책에서는 그렇게 표현한것 같습니다.
PMS는 디피-헬먼으로 만들지만, 세션키는 Nonce와 PMS로 만듭니다.
TLS 한정이라면 키생성에 관여한다고 볼 수는 있겠네요.
키교환을 ECDHE(디피-헬먼의 변형, 타원곡선 디피-헬먼)으로 한다면,
PMS는 클라이언트 DH 파라미터와 서버 DH 파라미터로 생성합니다.
(RSA는 PMS를 클라이언트에서 일방적으로 생성)
=> 맞습니다. 레몬 트리님 답글에 해당 내용도 포함되어 있습니다. 좀 더 풀어서 간단하게 설명하자면..
DH가 아닌 RSA의 경우에는 아래와 같은 과정을 거칩니다. (단순하게 표현한거라 알고리즘 교환등은 생략합니다)
1. 서버가 자신의 인증서를 클라에게 전송합니다.
- 인증서에는 공개키와, 공개키와 기타 정보를 CA가 디지털 서명한 서명(Signature)이 있습니다.
2. 클라이언트가 서버의 인증서를 받으면
- a. 서버의 인증서를 검증합니다. (CA인증서는 이미 클라PC에 있으며 이를 통해 (PKI & 디지털서명 참고) 변조가 없는지 확인합니다.)
- b. 세션 키(대칭 키)를 **랜덤으로** 만들어 서버 인증서에 있는 **공개키로 암호화** 하고 암호화된 값을 서버로 전송합니다.
(공개키로 암호화하면 해당 정보는 개인키로만 열 수 있습니다)
3. 서버는 암호화된 세션키를 받고 앞으로 해당 세션키로 임호화하여 서로 통신합니다.
-----
DHE의 경우에는 세션 개시때 서버가 임시 DH 키페어를 만들고 -> 서버 인증서로 DH 공개키를 사인해서 -> 클라에게 보내고 -> 클라는 임시로 DH 키페어를 만들어서 받은 DH공개키와 짬뽕해 세션키를 만들고 자신의 DH 공개키를 서버에게 보내면 키합의가 이루어 집니다.
TLS(SSL)은 위 키교환 뿐만 아니라 키를 교환할 때 해당 정보가 변조되었는지 확인하는 과정과 재전송 공격같은 공격에 대비하고 나중에라도 비밀키가 탈취당했을 때에 대한 대비도 해야하는 등 고려할것이 많습니다.
그래서 비대칭 암호화 + 디지털서명 + PKI + 대칭 암호화 여러 기술들의 총합이죠.
참고로 비대칭키는 수명이 짧습니다. 몇년 안에는 뚫린다고 보고 키를 주기적으로 변경하며 (그래서 공인인증서도 1년마다 재발급..ㅠㅠ)
RSA & DH의 경우 나중에 비밀키가 탈취되면 이전 통신내용을 알 수 있기 때문에 DH대신 DHE를 쓰는게 안전합니다.