2021 06 16

2021-06-16¶

https¶

참고 1: https://www.youtube.com/watch?v=H6lpFRpyl14
참고 2: https://coding-start.tistory.com/208
참고 3: https://opentutorials.org/course/228/4894
https가 필요한 이유? - http의 약점 - http만 가지고는 도청이 너무 쉬움. 중요한 내용 그대로 노출됨 - 통신 상대 확인 안하기에, 위장이 가능 - 완전성 증명 X, 변조 가능 - 다음과 같은 기능이 필요하기에 http+ssl 도입 1. 다른 사람들이 네트워크를 통해 전송한 내용을 훔쳐보더라도 못 알아 듣게 하기 위해 2. 클라이언트 입장에서 접속한 사이트가 믿을 만한 곳인지를 보장하기 위해
https? - ssl이라는 보안 프로토콜 위에서 동작하는 http - [SSL(Secure Socket Layer)] - 인터넷 상에서 데이터를 안전하게 전송하기 위한 인터넷 암호화 통신 프로토콜 - SMTP, Telnet에서도 사용가능 - 응용 계층과 전송 계층 사이에서 동작하는 독립적인 프로토콜 - 참고: https://security.stackexchange.com/questions/19681/where-does-ssl-encryption-take-place - HTTP 통신을 하는 소켓 부분을 SSL/TLS 프로토콜로 대체 - HTTPS는 직접 TCP와 통신하지 않고, SSL과 통신하게 됨 - 응용 계층의 http 프로토콜에서 사용자의 데이터 받고, "전송계층으로 캡슐화 되기 이전"에 SSL 프로토콜에 의해 사용자의 데이터 암호화 - 서버에서는 전송계층에서 세그먼트 받아 ssl 계층에서 데이터 복호화 한 후 응용계층에 보냄

대칭키 방식 vs 비대칭키 방식 - 대칭키 - 수신과 송신에 같은 암호화-복호화 적용 - 둘이 같은 키를 가지고 있기에 이를 통해 암호화-복호화 가능 - 하지만 같은 키를 "누군가 한 번" 한쪽에서 다른쪽에게 넘겨줘야 하기에 보안상 문제가 있음 - openssl을 통한 실습

# tiltext.txt를 tiltext.bin으로 암호화 (이때 대칭키를 직접 입력해줌)
$ openssl enc -e -des3 -salt -in tiltext.txt -out tiltext.bin
enter des-ede3-cbc encryption password: 대칭키
Verifying - enter des-ede3-cbc encryption password: 대칭키

#tiltext.bin을 decryptedtiltext.txt로 복호화 (이때 대칭키 입력해줘야함)
$ openssl enc -d -des3 -in tiltext.bin -out decryptedtiltext.txt;
enter des-ede3-cbc decryption password: 대칭키

- 비대칭키 - 공개키와 개인키로 구성 - 공개키는 그냥 누구나 볼 수 있도록 대중에 공개 - 다음과 같은 방식으로 네트워크를 통해 전송할 내용을 암호/복호화 가능 - Text --공개키로 암호화--> 암호화 된 Text --개인키로 복호화--> Text - Text --개인키로 암호화--> 암호화 된 Text --공개키로 복호화--> Text - 다음과 같은 방식으로 믿을만한 사이트인지 판별 - Client가 Server에 사이트 요청 - Server의 개인키로 암호화 된 내용 Client에게 전송 - Client는 공개키로 Server의 내용을 복호화해서 볼 수 있음 - openssl을 통한 실습

# 개인키 생성
$ openssl genrsa -out privatetil.pem 1024;
Generating RSA private key, 1024 bit long modulus (2 primes)
.........................+++++
.........+++++
e is 65537 (0x010001)
$ cat privatetil.pem
-----BEGIN RSA PRIVATE KEY-----
MIICXgIBAAKBgQDTf62Rubp2uSIaCibESRZT25JQ0Du8baz6vD8bi1Vpc7NYCOx7
5yFWNUUYA7b0MskbEnuOeKYVeJiYa7jIPblWkFKNAtl7lyFi2C8ogYkVuRX0xXYV
nJoIIdfoGiwSnR44ASAsPTWeMQVqmg7cpa7838HVNtV3XKncRmHL78z8LQIDAQAB
AoGBALzvNO2WPeVrEvSyFtmH9OMqpfV9X6+/RiSi37lKah2O1yqQpjk1S0mIwtVm
FBzn9VEy3J90VeGeXqriqCpxQUtb/B8QQeM6vCmn26YF0NYrhatzV8XnemXi3ak9
4Iy7CVls4LcprsO1SFR6VIJZ8SkrpuFfLCnKckJB0JcVxoxhAkEA8s17LFvr/oCr
4eP6OaCKjNzqwU/c7JHWVi1LRBlyKxzIMABjap/EeiDQg8rJVVs2oYwW7vSQfjPy
L2h0PbB/uQJBAN7+nPimdyeI6ZAcaS3fuDbjdyVPmEqVfPYSD8ZYVXARcpaT0GK5
H5OxSgzr59aftvPVmbvFNavULrbzN4LTkhUCQQDEHF/ullho+fjavU7wmNEPsagT
d7QTiD+831y5pmvmkprG2qlyB5WkpziEGpi/zqqzlPk5DGRg6wgkbpPk99hRAkEA
18qUpJqSnBOF0gtsTRQ98//TAKwxt5tJveZklZBNvZFkzgpkkeSLhiT+f9qaE7uj
E/sUNfz1nz5Jpoleop+SsQJAa8VY+ybF6NOgjoFEHJ/4wkjt4mrx3fve3hgExYjT
IrNmnxRHq3SdCTn6UQJHkBaf/xlZuWWW21cyDw5u/BcnwQ==
-----END RSA PRIVATE KEY-----

# 공개키 생성
$ openssl rsa -in privatetil.pem -out publictil.pem -outform PEM -pubout;
writing RSA key
$ cat publictil.pem
-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDTf62Rubp2uSIaCibESRZT25JQ
0Du8baz6vD8bi1Vpc7NYCOx75yFWNUUYA7b0MskbEnuOeKYVeJiYa7jIPblWkFKN
Atl7lyFi2C8ogYkVuRX0xXYVnJoIIdfoGiwSnR44ASAsPTWeMQVqmg7cpa7838HV
NtV3XKncRmHL78z8LQIDAQAB
-----END PUBLIC KEY-----

# 공개키를 통해 텍스트 파일을 암호화, 이를 개인키를 가진 소유자에게 전달하면 됨
$ openssl rsautl  -encrypt -inkey publictil.pem -pubin -in tiltext.txt -out tiltext.ssl;
$ cat tiltext.ssl
t�(�s��6�0V�a��İZ"6�C�-���3.�%��6E�r�ns�%
a�e|o)f�)no��;T
咜�5�+m���i7ΐZ�0�E�݌�!�4�D�I���֖����#J�U;C��H��~

# 개인키를 가진 소유자가 tiltext.ssl을 복호하 한 것을 볼 수 있음
$ openssl rsautl -decrypt -inkey privatetil.pem -in tiltext.ssl -out decrypted.txt;
$ cat decrypted.txt
tiltil

SSL - CA라는 SSL 공인 인증 기관이 있음. 여기서 SSL 발급 및 관리 - 브라우저는 CA들의 목록을 가지고 있음
https 인증 과정 1. Client는 "ClientRandomData"를 만들어 Server에게 전송 2. Server는 "ServerRandomData"를 만들어 "CA의 개인키로 암호화 된 SSL 인증서"와 함께 Client에게 전송 3. Client는 Server로 부터 받은 "CA의 개인키로 암호화 된 SSL 인증서"를 CA의 공개키로 복호화 함 4. 복호화한 SSL 인증서에는 "Server의 공개키"가 있음 5. Client는 "ClientRandomData + ServerRandomData"를 묶어 Client와 Server 사이의 "대칭키"를 생성함 6. Client는 "대칭키"를 "Server의 공개키"로 암호화하여 Server에게 전송 7. Server는 이를 "Server의 개인키로" 복호화 하여 Client가 만든 "대칭키"를 확인 8. 앞으로 둘 간의 통신에서 해당 대칭키를 사용 9. 데이터 전송이 끝난 후, 대칭키 폐지!
와이어샤크로 살펴보기 - - 참고: https://ask.wireshark.org/question/2745/why-wireshark-is-not-showing-http-or-https-packets-in-the-view/ - https 패킷 같은 건 없나봐...? - https == http over tls - 와이어샤크로 암호화된 컨텐츠를 해부할 수 없어 - 따라서 가장 높은 Layer의 패킷은 TLS의 패킷임 - - 3-way-handshake를 통한 TCP 연결 수립 확인 - 클라이언트 측 HTTP 요청 - 서버 측 TCP로 ACK(확인했다) 응답 - 서버 측 HTTP로 요청한 자료 전달

TCP/UDP¶

참고: https://www.youtube.com/watch?v=ikDVGYp5dhg
Transport Layer - 신뢰성: 데이터를 순차적, 안정적으로 전달 - 전송: 포트 번호에 해당하는 프로세스에 데이터를 전달
TCP - 신뢰성 있는 데이터 통신을 가능하게 해주는 프로토콜 - Connection 연결을 통한 양방향 통신 - 데이터의 순차 전송 보장 - 특징 - Flow Controll (흐름 제어) - Congestion Controll (혼잡 제어) - Error Detection (오류 감지) - Application Layer에서 내려온 정보를 잘라 TCP Segment로 바꿈 - 조금 짤라 앞에 TCP Header 붙임 - 3-way-handshake로 연결 수립 - 연결 수립 후 패킷 전송, 성공 전달 시 ACK, 유실 시 재전송 - 4-way-handshake로 빠이빠이