[네트워크] Secure e-mail, SSL, MAC

네트워크 관련 글 순서(참조 영상 기준)

애플리케이션 계층
- 네트워크 애플리케이션의 원리
- DNS
- TCP를 이용한 Socket 프로그래밍

전송계층
- 전송 계층 서비스의 원리
- rdt 원리
- 연결 지향 전송: TCP
- TCP 흐름 제어(3-way handshake, 4-way handshake)
- TCP 혼잡 제어

네트워크 계층
- 네트워크 계층 서비스
- Network Address Translation(NAT), DHCP
- 라우팅 알고리즘(Link State, Distance Vector)
- 계층적 경로 변경(AS)

링크 계층
- 다중 엑세스 프로토콜
- LANs(근거리 통신망)

무선 및 모바일 네트워크
- 무선 네트워크

웹 요청 시 일어나는일

네트워크 보안
- 대칭키 & 공개키,RSA 암호화
- Secure e-mail, SSL, MAC
- IPSec(ESP), Firewall(방화벽)

 

Secure e-mail: 이메일 보안

대칭키를 이용해 메세지를 암호화하는데, 그에 맞는 대칭키를 수신자가 가진 공개키로 암호화해서 같이 보냄

그럼 수신자만 개인키로 복호화해서 대칭키를 받아서 메세지를 복호화 할 수 있음

 

digital signature 를 통해 어떤 송신자가 보낸 것인지 확인 가능

전자서명 구현 구조

전자서명 관련 그림 참조 블로그

 

SSL(Secure Sockets Layer)이란

웹사이트와 브라우저(혹은, 두서버) 사이에 전송된 데이터를 암호화해주는 계층.

 

• 최근에는 TLS라고도 부름
• 애플리케이션 계층과 TCP/IP 계층 사이에 있음
• 애플리케이션계층에서 메세지마다 일일히 다 암호화 해주긴 힘드니까 나온 기술
• SSL이란 소켓을 사용하여 암호화 자동 처리
• HTTPS란 SSL 프로토콜위에서 작동하는 프로토콜을 뜻함.(기존엔 TCP 소켓으로 진행)

 

SSL 인증서

• 클라이언트와 서버간의 통신을 제 3자가 보증해주는 전자화된 문서
• 클라이언트가 서버에 접속하면 서버는 클라이언트에게 인증서 정보를 전달해줌
• 클라이언트는 이 인증서 정보가 신뢰할 수 있는지 검증
  • 클라이언트가 의도한 서버에 접근한게 맞는지 확인

 

CA(Certificate Authority) 

• 인증서를 발급해주는 기업
• SSL을 통해서 암호화된 통신을 제공할려면 CA를 통해 인증서를 구입해서 진행해야함

 

 

SSL 동작원리

 

1. 클라이언트는 서버에 "client hello" 라는 메세지를 전달. 이때 암호화된 버전,암호 알고리즘, 압축 방식 등을 담아서 보냄.
2. 서버는 클라이언트에서 보낸 정보를 받고, 세션ID와 CA 공개 인증서를 "server hello" 메시지와 함께 응답. CA 인증서엔 연결과정 속 암호화에 사용될 공개키가 담겨 있음.
3. 클라이언트 측은 서버에서 보낸 CA 인증서가 유효한 지 내장된 CA 목록에서 확인하는 과정을 진행
4. CA인증서에 대한 신뢰성이 보장되면, 클라이언트는 난수 바이트를 생성하여 서버의 공개키로 암호화. 이 난수 바이트는 대칭키를 정하는데 사용이 되고, 앞으로 서로 메세지를 통신할 때 암호화하는 용도로 사용.
5. 만약 2번과정에서 서버가 클라이언트 인증서를 함께 요청했으면, 클라이언트의 인증서와 클라이언트 개인키로 암호화된 임의의 바이트 문자열을 함께 전송
6. 서버는 클라이언트의 인증서 확인 후, 난수 바이트를 자신의 개인키로 복호화 후 대칭 마스터 키 생성에 활용
7. 클라이언트는 연결과정이 완료되었다는 "finished" 메시지를 서버에 전송 및 지금까지 보낸 교환 내역들을 해싱 후 그 값을 대칭키로 암호화하여 같이 전송.
8. 서버도 동일하게 교환 내용을 해싱 한 후 클라이언트에서 보내준 값과 일치여부 확인. 일치하면 서버도 클라이언트에게 "finished" 메시지를 대칭키로 암호화하여 전송
9. 클라이언트는 해당 메시지를 대칭키로 복호화하여 서로 신뢰할 수 있다는것을 알고 대칭키로 데이터 주고 받음

 

즉 공개키와 대칭키를 둘다 사용하며, 연결과정에선 공개키를 통한 연결 후 대칭키를 이용하여 통신을 주고 받음.

 

이때 생성된 대칭키를 바로 사용하지 않고, 4가지 정도의 키로 생성함

4개의 키로 나누는 이유는 키가 노출되었을때, 피해를 최소화하기 위해서

 

 

Record Protocol

• SSL 프로토콜의 구성요소 중 하나
• 메세지를 암호화와 무결성을 위한 MAC 생성하여 통신을 수행하게 도와주는 SSL 하위 프로토콜

 

 

1. Protocol: Record 프로토콜이 감싸고 있는 프로토콜이 어떤 프로토콜인지 나타내는 것
2. Version: SSL의 버전 표시
3. Length: 데이터의 길이
4. Protocol Message: 데이터
5. MAC: 데이터의 MAC 값

 

레코드 프로토콜의 동작 방식은

• 메세지를 단편화
• 단편화된 메세지를 압축 및 압축된 데이터의 MAC 추가
• 압축된 데이터와 MAC을 같이 암호화
• Record 헤더 추가하여 전송

 

reordering Attack

• 문제: 패킷의 내용을 서로서로 바꿔놓는 공격
• 해결: MAC엔 시퀀스넘버(SSL에서 사용 시퀀스넘버)도 같이 넣어져 있음

 

truncation Attack

• 문제: TCP연결을 강제 종료시키는 공격(FIN데이터 보내기)
• 해결: SSL Records에 type이라는 필드를 추가하여 끝났을때만 1로 보내짐. MAC에도 해당 내용이 들어있음.

 

MAC(Message Authentication Code)이란?

• 메세지가 원하던 송신자에서 온것인지 판단해주는 코드
• Hash Function을 통해 만들어진 것이 MAC
• 간단설명
  • Message를 hash를 한후 대칭키로 암호화한 MAC을 만들고, Message와 MAC을 전송
  • 수신자는 Message hash한후 대칭키로 암호화하고, 같이 온 MAC과 비교하여 일치하는지 확인
  • 일치한다면, 원하는 송신자가 보낸것과 데이터가 중간에 변화하지 않은것을 확인할 수 있음
• 위의 과정에서 대칭키 과정만 빠진 것이 MDC(Message Detection Code)
  • 메세지의 위조/변조만 검증 가능. 송신자에대한 신뢰는 어려움
  • 공격자가 중간에 탈취하여 새로운 메세지와 MDC를 보내면 이것이 변조된지 결국 확인 불가능

 

 

http에 검색했을때 warning 뜨는것 

국가에서 일정 링크를 warning 경고를 띄울 수 있는 방법

 

일정 링크와 tcp connection까진 이루어짐

그럼 그 후 http request가 보내지면, 그때 중간의 라우터같은 곳에서 request에 해당 url이 담겨져 있는것을 보면,

차단하고 본인이 해당 링크인척 응답을 보내줌.(warning)

 

만약 https를 사용한다면 차단이 불가능(request를 보고 차단하는데 https에선 암호화가 되어있어서 확인 불가)

 

 

---

참조

 

KOCW 네트워크 강의 - 한양대 2018 1학기 이석복 교수님

컴퓨터네트워크

전자서명 관련 그림 참조 블로그

전자서명 (Digital Signature) > 도리의 디지털라이프