Enochkon's blog

들어가며

• 왜 흐름 제어와 혼잡 제어를 4계층에서 수행해야 하는가?
• 흐름 제어란 무언인가?
• 혼잡 제어란 무엇인가?

왜 흐름제어(flow control)와 혼잡제어(congestion control)이 필요할까?

• 송신 노드와 수신 노드의 용량 및 처리 속도는 정해져 있다.
  • 각 노드의 한계가 있기 때문에 데이터가 너무 많이 전송될 경우 노드가 죽을 가능성이 존재한다.
• 현실에서 사용하는 네트워크는 비신뢰성을 가지고 있기 때문에.
  • 순서가 바뀌거나 데이터를 잃어 버릴 수 있다.
  • 네트워크에 데이터가 너무 많아 혼잡하거나 수신자가 과부화가 걸릴 수 있다.

흐름 제어 (Flow Control)

• 송신측과 수신측의 데이터 처리 속도 차이를 해결하기 위한 기법
• 수신자에게 받는 rwnd(로 제어.흐름 제어가 필요한 이유
• 수신측의 데이터 처리 속도(or 용량)이 송신측보다 더 빠르면 아무 문제가 없다.
  하지만 송신측의 데이터 처리 속도가 더 빠르다면, 수신측에서 데이터 손실이 발생할 수 있다.
  -> 이를 방지하기 위해서 데이터 흐름을 제어해야 함.

흐름제어에서 속도를 제어하기 위한 두가지 방식

• Stop and wait
  • 매번 전송한 패킷에 대해 확인 응답을 받아야지만 그 다음 패킷을 전송하는 방법
  • 간단하고 확실한 방법이다.
  • 하지만 앞서 보낸 데이터에 대한 응답이 도착했을 때만 보낼 수 있으므로 비효율적이여서 잘 사용하지 않는다.

• Sliding Window
  • 수신 측에서 설정한 윈도우 크기만큼 송신측에서 데이터를 전송
  • 윈도우 크기는 수신측의 여유공간을 바탕으로 동적으로 변경됨.Sliding Window

혼잡 제어 (Congestion Control)

• 송신측의 전송 속도와 네트워크의 처리속도의 차이를 해결하기 위한 기법
• 송신측에서 가지고 있는 cwnd로 제어혼잡 제어가 필요한 이유
• 현재 네트워크에 너무 많은 데이터가 보내지고 있는 상황에서 송신자가 데이터를 보내려고 하는 상황
  -> 라우터가 너무 많은 데이터를 처리하지 못해 손실이 나며 느려짐
  -> 네트워크 전체가 느려지게 됨.

• 이 그림에서 만약 빨간 선 쪽에서 데이터 손실이 일어나게 된다면 포함된 라우터들이 느려지면서 다른 모든 데이터 흐름이 같이 느려지게 된다.

혼잡 제어의 방식

• AIMD 기법
  • Additive Increase Multplicative Decrease
  • cwnd (congestion window)를 기준으로 해결
  • 처음에 패킷을 1MSS(Maximum segment size, 전송할 수 있는 최대 세그먼트 크기)로 전송하다가, 패킷 전송에 실패하게 되면 네트워크가 혼잡하다고 판단하여 보내는 패킷의 양을 반으로 줄임
• Slow Start
  • 패킷 전송을 1MSS씩 증가시키는것이 아니라 2의 지수승으로 늘린다.
  • 만약 패킷이 손실될 경우 다시 window size를 1 MSS로 줄인다.
  • 임계점 (ssthresh)
    • 임의로 slow start를 여기까지 사용하겠다! 라는 의미
    • 임계점은 패킷 손실이 날 경우 줄어들고, 그렇지 않을 경우 늘어난다. (동적이다)
• Fast Retransmit
  • 손실 감지 알고리즘으로 ACK Duplicated나 Timeout이 발생하면 본인의 윈도우를 수정
  • 패킷 손실이 발생하면 cwnd를 초기의 윈도우 크기로 재설정
• Fast Recovery
  • 패킷 손실이 났을 때 3 duplicate ack과 time out으로 구분
  • 중복 상태에서는 수신측으로 전달이 된다는 의미이므로 cwnd를 현재의 반으로 설정
  • time out이 났을 때에는 네트워크가 혼잡하다고 생각하여 cwnd를 초기화
   

• TCP Tahoe
  • Slow Start, AIMD, Fast Retransmit의 결합

• TCP Reno
  • TCP Taeho에서 Fast Recovery 추가

기타

• 만약 cwnd와 rwnd의 크기가 다르면 tcp는 무엇을 기준으로 보낼까?
  -> 둘다 만족하기 위해서 둘중에 작은 것을 기준으로 삼아 통신을 한다.
• mac에서 window size 확인하기

  sudo tcpdump -i any -n #tcp 패킷을 캡쳐하는 명령

   

-> 여기서 나오는 win이 바로 window size (rwnd, cwnd 실시간으로 네트워크의 상황을 반영해 추론하므로 직접적으로는 표시되지 않는다.)

HTTP를 어떻게 안전하게 할 수 있을까?

• http의 보안버전은 효율적이고 이식성이 좋고, 관리가 쉬워야 하며, 현실 세계의 변화에 대한 적응력이 좋아야한다. 또한 사회와 정부의 요구사항에도 맞아야한다.
• 다음을 제공해주는 HTTP의 보안기술이 필요하다.
  • 서버 인증 : 클라이언트는 자신이 위조된 서버가 아닌 진짜와 이야기하고 있음을 알 수 있어야함
  • 클라이언트 인증 : 서버는 자신이 가짜가 아닌 진짜 사용자와 이야기하고 있음을 알 수 있어야 한다.
  • 무결성 : 클라이언트와 서버는 데이터가 위조되는것을 방지해야한다.
  • 암호화 : 클라이언트와 서버가 서로 안전하게 대화해야 한다.
  • 효율 : 저렴한 클라이언트나 서버도 이용할 수 있도록 알고리즘은 충분히 빨라야 한다.
  • 편재성(Ubiquity) : 프로토콜은 거의 모든 클라이언트와 서버에서 지원되어야 한다.
  • 관리상 확장성 : 누구든 어디서든 즉각적인 보안 통신을 할 수 있어야 한다.
  • 적응성 : 현재 알려진 최선의 보안 방법을 지원해야 한다.
  • 사회적 생존성 : 사회의 문화적, 정치적 요구를 만족시켜야 한다.

HTTPS

• http를 안전하게 만드는 방식 중에서 가장 인기 있는 것
  • 보안 전송 계층을 통해 전송되는 http이다
• 모든 주류 브라우저와 서버에서 지원한다.
  • firefox, safari, chore, edge 등등
• 모든 http 요청과 응답 데이터는 네트워크로 보내지기 전에 암호화된다. https는 http의 하부에 “전송 레벨 암호 보안 계층”을 제공함으로써 동작.
  → 이 보안 계층은 안전 소켓 계층(SSL, Secure Sockets Layer)혹은 그를 계승한 전송 계층 보안(TLS, Transport Layer Security)을 이용하여 구현.
  → SSL과 TLS는 사실상 같기 때문에 SSL이라고 표기하기도 함
  • SSL : Netscape사에서 1995년에 만든 통신 프로토콜
  • TSL : SSL의 3.0버전을 가지고 Netscape가 개발에서 빠지며 국제 인터넷 표준화 기구 **IETF(Internet Engineering Task Force)**에서 만든 프로토콜
    ⇒ 현재는 SSL 2.0 및 3.0이 전부 사용 중지, 사실상 TLS만 사용.
    ⇒ 또한 TLS 1.0과 1.1도 사용 중지 예정
  • ![[123.png]]
    ![[765432.png]]

→ 대부분의 경우, tcp 입력/출력 호출을 ssl 호출로 대체하고, 몇가지의 설정만 바꿔주면 된다.

• 인코딩 및 디코딩 작업은 대부분 SSL 라이브러리 안에서 일어나기 때문에 http의 로직을 크게 변경할 필요가 없다.
  → 대부분의 경우, tcp 입력/출력 호출을 ssl 호출로 대체하고, 몇가지의 설정만 바꿔주면 된다.

암호(cipher)

• 암호 : 메시지를 인코딩하는 어떤 특정한 방법과 나중에 그 비밀 메세지를 디코딩하는 방법을 말함.
• 원본 메세지(텍스트 or 평문)에 암호를 적용하면 암호문이 된다.

• 역사상 최초의 암호 : 스키테일 암호

• 카이사르의 순환암호
• 메세지의 각 글자를 알파벳 순서상 세번 뒤의 글자로 바꾸는 방법 사용

디지털 암호

• 디지털 시대로 넘어오면서 두가지의 변화
  • 속도 및 기능에 대한 전폭적인 성장, 훨씬 더 복잡한 인코딩과 디코딩이 가능해짐
  • 매우 큰 키를 지원하는 것이 가능해져 단일 암호 알고리즘으로 키의 값마다 다른 수조개의 암호 알고리즘을 만들어 낼 수 있게 됨.
• 평문 메세지 P, 인코딩 함수 E, 디지털 인코딩 키 e가 주어졌을 때 암호문 C를 생성할 수 있다.
  ![[62138761283.png]]

자세한 암호화에 관한 내용은 전 게시글에 존재한다

사이트 인증서 검사

• 날짜 검사
  • 인증서의 유효기간을 검사
• 서명자 신뢰도 검사
  • 발급받은 CA가 믿을만한 기관인지 검사
• 서명 검사
  • CA의 공개키를 사용해 인증서의 무결성 검증
• 사이트 신원 검사
  • 인증서의 도메인 이름과 서버의 도메인 이름이 맞는지 검사

와이어 샤크로 ssl handshaking 뜯어보기

• 와이어 샤크를 사용해서 naver에 접속할 때 ssl 인증이 어떻게 이루어지는지 확인하기
• naver의 ip주소를 알아내기 위해서 nslookup 명령어 사용
  • 와이어샤크에서 ipv6를 사용하길래 네이버의 ipv6 주소를 알아냄

• 와이어 샤크에서 naver의 ssl handshake만 보기 위해서 설정

• 설정 후 네이버 창을 켠뒤 와이어샤크 측정 종료

1. client hello
   • 클라이언트가 서버에 처음으로 연결을 요청할 때 보냄
   • client의 SSL 버전, 세션 ID, Cipher Suites 등을 보낸다.

2. server hello

• 클라이언트의 응답을 받았으며 SSL/TLS Handshake 를 진행
• 클라이언트에서 받은 Cipher Suites 목록 중에 사용할 버전 확정해서 응답

3. Certificate

• 서버가 클라이언트에게 자신의 디지털 인증서를 제공
• 이 메세지에 있는 디지털 인증서를 기반으로 클라이언트가 서버의 신뢰성을 확인.

4. Server Key Exchange

• 서버 측에서 키 교환을 위해 서버의 인증서를 넘어서는 추가 데이터가 필요할 때 요청하는 메세지
  Server Hello Doine
  • ssl handshake에서 서버의 역할이 완료되었음을 알림 (서버가 보낼 건 다보냈다)
   

5. Client key Exchange

• 클라이언트에서 공유할 비밀키 생성
  change Cipher Spec
• 이제부터는 아까 위에서 협상했던 암호화 방법으로 통신을 전환하자고 알리는 것
  
  

6. New Session Ticket

• 일종의 캐시 역할.
• 클라이언트가 나중에 연결 시 빠른 연결을 위해 세션 티켓을 저장
  change Cipher Spec
• 클라이언트의 요청과 똑같이 이제 암호화된 통신이라는 것을 의미
  
  

7. Application Data

• 클라이언트에서 암호화된 통신으로 서버로 전송

8. Application Data

• 서버에서도 클라이언트에 대한 응답으로 암호화된 데이터 전송

Reference

https://a-gyuuuu.tistory.com/357
https://doongdangdoongdangdong.tistory.com/249
https://mandoo12.tistory.com/26

개요

• SSL(Secure Sockets Layer)
• TLS(Transport Layer Security)
• 왜 SSL을 사용해야 하는가?
• 암호화 기법
• SSL 인증서
• SSL Handshake

SSL(Secure Sockets Layer)

• ssl이란 "웹사이트의 ID를 인증하고 암호화된 연결을 생성하는 인터넷 보안 프로토콜"
• Netscape는 개발된 프로토콜로 SSL 1.0은 1995년 개발
  -> 하지만 1.0의 경우 많은 이슈가 있어 공개되지 않았고, 1996년에 2.0부터 공개되기 시작
• 개인정보 보호, 인증, 데이터 무결성을 보장
• 클라이언트와 웹 서버 사이에서 동작

TLS(Transport Layer Security)

• SSL과 거의 동일한 프로토콜
• 특정 회사(Netscape)에 의해 개발된 SSL을 인터넷 표준화 기구인 IETF (Internet Engineering Task Force)에서 표준화
• SSL 3.0 버전을 기반으로 TLS 1.0을 발표

• 윈도우에서 지원되는 SSL과 TLS
  

  

현재는 모든 SSL은 지원하지 않고, TLS만 사용한다.

왜 SSL을 사용해야 하는가?

• ssl같은 보안을 적용하지 않고 그냥 데이터를 주고 받는다면 제 3자가 데이터를 쉽게 탈취할 수 있다.

SSL이 적용되지 않은 경우

• ssl이 적용되지 않으면 위 그림에서 처럼 "High Value Information"라는 문자열이 그대로 전송
• 제 3자가 데이터를 탈취하기 쉽다.

SSL 적용된 경우

• ssl이 적용된 경우에는 데이터가 암호화되어서 보내진다.
• 제 3자가 탈취한다 해도 복호화하기 힘들기 때문에 상대적으로 안전해진다.

암호화 방식

• 사용하는 암호화 방식은 대칭키와 비대칭키를 혼합해서 사용한다.

대칭키 암호화

• 대칭키 암호화 : 인코딩 할 때 사용하는 키와 디코딩 할 때 사용하는 키가 같다. (발송자와 수신자는 같은 비밀키를 알고 있어야 한다.
  ex) DES, Triple-DES, RC2, RC4

• 비밀키의 보안이 제일 중요하다. 대부분의 경우, 인코딩&디코딩 알고리즘은 공개적으로 알려져 있어서 키를 알면 암호를 풀 수 있다.
• 열거 공격(Enumeration Attack) : 가능한 모든 수를 대입해보기 (브루트포스)
  → 이를 방지하기 위해 키값을 늘림. 128비트의 암호키는 2의 128승 의 값이 가능…

      (340282366920938463463374607431768211456가지의 값)

• 대칭키 암호의 단점
  • 발송자와 수신자가 동일한 공유키를 가져야함.
    → 발송자와 수신자의 수 만큼 키가 있어야함, 많은 수의 키를 관리해야함.
  • 공유키가 탈취되면 모든 문서의 암호가 풀릴 수 있음

공개키(비대칭키) 암호화

• 공개키 암호화 : 두 개의 비대칭 키를 사용, 인코딩 키는 공개되어 있고 디코딩 키만이 보안 유지.
  ex) RSA
• 호스트가 인코딩 키를 공개하면, 이 인코딩 키를 사용해서 호스트에게 암호화된 메세지를 보낼 수 있다.
  → 그리고 이 암호화된 메세지는 오직 호스트가 가지고 있는 디코딩 키를 사용해서 볼 수 있다.
  

  

• 대칭키와는 달리 인코딩키를 공유하므로 키의 개수를 줄일 수 있다.

데이터 전달 과정

1. 송신자가 수신자의 공개키를 사용해서 데이터를 암호화 한다.
2. 수신자는 본인만이 가지고 있는 개인키를 사용해서 데이터를 복호화해서 사용한다.

공개키의 단점

• 연산속도가 느리다.

디지털 서명

• 공개키 암호화 방식을 사용해서 구현
• 보내는 이의 개인키를 사용해서 서명을 작성 -> 받는 쪽에서 보낸이의 공개키를 사용해서 복호화

앨리스가 밥에게 보낼 때

1. 앨리스는 밥의 공개키(PK/bob) 을 이용하여 암호화 한다.
2. 앨리스는 앨리스의 개인키(SK/Alice)을 이용하여 서명한다.
3. 밥은 밥의 개인키(SK/bob)을 이용하여 복호화 한다.
4. 밥은 앨리스의 공개키(PK/Alice)을 이용하여 서명을 검증한다.(앨리스가 보낸사항임을 확인함)

앨리스가 밥에게 보낼 때 (해쉬 포함)

1. 앨리스는 밥의 공개키(PK/bob) 을 이용하여 암호화 한다.
2. 앨리스는 문서내용(Hello, Bob)을 해쉬한다.
3. 이 해쉬에 앨리스의 개인키(SK/Alice)를 이용하여 서명한다.
4. 밥은 밥의 개인키(SK/bob)을 이용하여 복호화 한다.
5. 밥은 위의 복호화한 내용을 해쉬한다.
6. 밥은 앨리스에게서 온 서명을 앨리스의 공개키(PK/Alice)을 이용하여 서명을 검증(복호화)한다.
7. 위의 복호화된 값과, 5의 해쉬값이 일치하는지 확인한다. (앨리스가 보낸사항임을 확인함)

간단한 실습

대칭키

# txt 파일 생성
echo "hihihi" > aa.txt

# 1234라는 키를 사용해서 -aes-256-cbc 방법을 사용해서 암호화. 
openssl enc -aes-256-cbc -salt -in aa.txt -out ciphertext.bin -k 1234

# 같은키와 같은 방식으로 복호화
openssl enc -d -aes-256-cbc -in ciphertext.bin -out decrypted.txt -k 1234

비대칭키

# rsa방식으로 1024bit 길이로 키 생성
openssl genrsa -out private.pem 1024;

# private.pem에 대한 공개키 생성
openssl rsa -in private.pem -out public.pem -outform PEM -pubout;

# 공개키를 사용해서 파일 암호화
openssl pkeyutl -encrypt -inkey public.pem -pubin -in aa.txt -out file.ssl;

# 비밀키를 사용한 파일 복호화
openssl pkeyutl -decrypt -inkey private.pem -in file.ssl -out decrypted.txt

SSL 인증서

• SSL 인증서는 클라이언트와 서버간의 통신을 제3자가 보증해주는 전자화된 문서
• 보통 CA라고 불리는 공인된 기관에서 유료로 발급
• 인증서 내용
  1. 서비스의 정보 (인증서를 발급한 CA, 서비스의 도메인 등)
  2. 서버 측 공개키 (공개키의 내용, 공개키의 암호화 방법)

CA

• CA(Certificate authority) 혹은 Root Certificate 라고도 불림
• 민간기업 중 엄격한 심사를 통해서 선정된 SSL 인증서 발급 기업
• 이 CA는 기본적으로 브라우저에 내장되어 있다.

• 맥의 경우 키체인에서 CA 인증서들을 확인할 수 있다.

SSL 인증서가 서비스를 보증하는 방법

1. 웹 브라우저가 서버에 접속할 때 서버는 제일 먼저 인증서를 제공
2. 브라우저는 이 인증서를 발급한 CA가 자신이 내장한 CA의 리스트에 있는지를 확인
3. 확인 결과 서버를 통해서 다운받은 인증서가 내장된 CA 리스트에 포함되어 있다면 해당 CA의 공개키를 이용해서 인증서를 복호화
   => 인증서를 복호화 할 수 있다는 것은 이 인증서가 CA의 비공개키에 의해서 암호화 된 것을 의미
   => 즉 안전하다.

SSL Handshake

• 파란 부분은 tcp handshake
• 노란 부분이 ssl handshake

1. ClientHello
   • client측에서 서버에 연결을 요청한다. (인사?)
   • session id, ssl protocol version, cipher suite 목록 등의 정보를 담아서 전송
2. ServerHello & Certificate, ServerHelloDone
   ServerHello
   • 1번에서 클라이언트에서 받은 인사(Client Hello 패킷)에 대해 서버가 응답
   • ssl protocol version, client suite중 하나 선택해서 응답
     Certificate, ServerHelloDone
   • Server 의 SSL 인증서 내용을 클라이언트에게 전송
3. client 에서 server 의 SSL 인증서 검증
   • 서버에서 받은 인증서 정보를 가지고 유효한 인증서인지 검증한다.
4. Client Key Exchange
   • 서버의 인증서 검증을 마친 후, 클라이언트는 서버와 통신하기 위한 대칭키를 생성한다.
   • 이 생성한 대칭키를 서버의 공개키를 사용해서 암호화 해서 서버에게 전송한다.
5. Server / Client SSL Handshake Finished
   • 서버가 암호화된 대칭키를 받아서 복호화에 성공하면 연결이 끝난다.

기타

무료 인증서 발급 사이트 목록

1. Let’s Encrypt : https://letsencrypt.org/
2. Comodo Free SSL : https://www.gogetssl.com/domain-validation/comodo-free-ssl/
3. CloudFlare One-Click SSL : https://www.cloudflare.com/ssl/
4. AWS Certificate Manager : https://aws.amazon.com/ko/certificate-manager/

Reference

https://hstory0208.tistory.com/entry/SSL-%EC%9D%B4%EB%9E%80-TLS-%EC%9D%B4%EB%9E%80
https://captcha.tistory.com/51
https://support.cafe24.com/hc/ko/articles/8469947344409-SSL%EC%9D%B4%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80%EC%9A%94-
https://velog.io/@yjw8459/%EC%9B%B9-%EC%82%AC%EC%9D%B4%ED%8A%B8-%EB%B3%B4%EC%95%88-SSL%EC%9D%B4%EB%9E%80
https://12bme.tistory.com/80
https://arc.net/l/quote/gqzfvkyb