기본적으로 TCP 통신에 사용되는
3-way handshaking나 4-way handshaking에 대해서는
들어본 적 있었는데,
https에 사용되는 ssl handshaking에 대해서는
ssl의 존재만 알고 있었다.
그래서 이번엔 handshaking들에 대한 정리를 하고자 한다.
무작정 handshaking에 대해만 설명하긴 뭣하니
간단히 tcp, udp와 https에 대한 설명도 하려한다.
tcp/udp
tcp는 transmission control protocol의 약자이고,
udp는 user datagram protocol의 약자이다.
OSI 7계층에선 4계층, TCP/IP 4계층에선 3계층으로 둘 다 transport layer에서
발생하는 연결 방식이다.
tcp
tcp의 경우 연결 지향형 프로토콜로
3-way handshaking 방식으로 연결하고,
4-way handshaking 방식으로 연결을 해제한다.3-way handshaking 방식으로 연결함에 따라
- 패킷의 전송 순서를 보장한다.
- 데이터의 처리 속도를 조절하여 수신자의 버퍼 오버플로우를 방지한다. (흐름 제어)
- 네트워크 내에 패킷의 수가 과하지 않게 조절한다. (혼잡 제어)
- 전송은 양방향으로 이루어지며, 각 연결은 정확한 종점을 가지고 있다.
udp
udp는 비연결형 프로토콜로
데이터를 데이터 그램 단위로 처리한다.
연결에 할당되는 경로가 없기 때문에
각각의 패킷은 다른 경로로 전송되고 독립적인 관계이다.
- tcp와 달리 연결과 해제하는 과정이 없다.
- 흐름 제어, 혼잡 제어가 없어 신뢰성이 낮다
- tcp 보다 전송 속도가 빠르다.
3/4-way handshaking
앞서 설명했듯이 tcp의 연결과 해제를 담당하는 과정이다.
3-way
- CLOSED 상태였던 클라이언트에서 임의의 난수로 sequence number를 지정하고,
SYN 패킷을 서버로 전송한다. 이후 SYN_SENT 상태로 대기한다.- SYN 패킷을 받은 서버는 받은 sequence number에 1을 더하여 ACK 패킷으로 만들고,
새로운 임의의 난수로 sequence number를 지정하여 SYN 패킷을 클라이언트에 전송한다.
이후 SYN_RECIVED 상태로 대기- 클라이언트는 받은 ACK 패킷과 SYN 패킷과 비교하고,
받은 SYN 패킷의 sequnce number에 1을 더하여 ACK 패킷으로 만들어 서버로 전송한다.
이후 ESTABLISHED 상태로 대기- ACK 패킷을 받은 서버는 전송했던 SYN패킷과 비교하고 ESTABLISHED 상태로 대기
SYN은 synchronize sequence number의 약자이고
ACK는 acknowledgement의 약자이다.
4-way
- 클라이언트에서 FIN 패킷을 서버로 전송하여 서버와 클라이언트의 연결을 해제 시도
패킷을 보내고 FIN_WAIT1 상태로 대기- FIN 패킷을 받은 서버는 ACK 패킷을 클라이언트에 전달한다.
서버는 CLOSE_WAIT 상태로 대기하고 실행 중인 어플리케이션에 close를 명령
ACK 패킷을 받은 클라이언트는 FIN_WAIT2 상태로 변경
서버에서 close( )명령이 끝나면, FIN 패킷을 전송하고 LAST_ACK상태로 대기- 클라이언트는 FIN 패킷을 받으면 ACK로 응답하고
TIME_WAIT 상태로 대기
TIME_WAIT 시간이 끝난 이후 CLOSED- ACK를 받은 서버는 바로 CLOSED
이 때 세 번째 과정에서 TIME_WAIT를 하는 이유는
서버에서 FIN 패킷을 보내고 ACK 패킷을 받는 사이
지연이나 유실등으로 재전송으로 인해
FIN 패킷 보다 늦게 도착할 수 있기 때문에
일정시간 동안 연결을 유지하여 패킷을 기다리기 때문
https/ssl
https는 http 연결에서 전송되는 패킷을 암호화하여 전송한다.
이때 ssl(secure sockets layer)가 사용되는데,
현재 https는 표준이고, ssl은 tls(transport layer security)로 변경되었지만,
여전히 ssl로 불리우고 있다.
tls(ssl) handshaking
- 클라이언트에서 서버로 Client Hello 패킷을 전송한다.
이 패킷에는
- 클라이언트에서 사용하는 tls version
- 클라이언트가 지원하는 암호화 방식
- 클라이언트가 생성한 난수
- 첫 handshake 이후 사용할 session id (최초 0)
- 클라이언트가 접속하고자 하는 도메인을 담은 SNI
가 담겨있다.
- 패킷을 받은 서버는 Sever Hello로 응답한다.
이 패킷에는 Client Hello와 비슷하게
- tls version
- 서버가 사용가능한 암호화 방식
- 서버가 생성한 난수
- session id
Client Hello의 session id가 0일 때 새로 session id를 생성
아닐 때 session id가 유효한지 검증
- Server Certificate
서버의 ssl인증서를 클라이언트에 보낸다.ssl인증서를 받은 클라이언트는 브라우져에 내장된 CA list에서 검증
검증 완료 시 클라이언트가 생성한 난수와 서버가 생성한 난수를 조합하여
pre master secret생성
이를 서버의 공개키로 암호화해 대칭 키 생성
- Server Hello Done
클라이언트에게 보낼 메세지를 모두 보냈다는 뜻
- Client Key Exchange
클라이언트가 만들었던 대칭 키를 서버에게 전송
- Key Generation
대칭 키를 성공적으로 공유 했다는 뜻
- Cipher Spec Exchange
상호간에 전송되는 메세지는 대칭키로 암호화 하겠다는 뜻
대칭/비대칭 키 암호화
대칭 키 암호화는
상호간에 암호화 하는 키를 주고 받아
데이터를 해당 키로 암호화하는 방식이다.
이 때 키를 "주고 받기" 때문에 노출 될 가능성이 있어
데이터를 암호화 하나 마나인 것이다.
비대칭 키 암호화는
한 쪽에서 공개 키와 비밀 키를 가지고 있고,
데이터를 공개 키로 암호화 하면 비밀 키로만 복호화 할 수 있다.
비대칭 키 암호화 방식만 사용하여 통신을 한다면,
양쪽에서 비대칭 키 암호화를 해야하는데,
비대칭 키 암호화 방식은 대칭 키 암호화 방식보다 훨씬 비효율 적이다.
그래서 ssl(tls)에서 암호화할 때 두 방식을 혼합하여 사용한다.
대칭 키 방식으로 암호화 할 때
대칭 키를 비대칭 키 방식으로 암호화 하여 첫 통신(ssl handshaking)때
클라이언트에서 서버의 공개키로 암호화 해 전달하고,
서버는 비밀키로 복호화 해 대칭 키를 알아내는 방식인 것이다.
어느 정도 이해 했고, 머리 속에 잘 들어온거 같아
답할 수 있을 거 같은데
면접 때 잘 말할 수 있었으면..
