- 4월 21일(목)
- Flexbox 사용해봤나요? 사용해봤다면 어떻게 사용했나요?
- css margin, padding 각각 어떻게 사용하며, 차이점은 무엇인지 설명해보세요
- position을 어떻게 적용했는지 설명해보세요
- Restful API에 대해서 아는대로 설명해보세요
- http와 https의 차이에 대해 아는대로 설명해보세요
- HTTP Method 중 GET, POST의 차이를 설명해보세요
http과 https의 탄생요약
https는 1994년 개발되었으며 쓰이기 시작한 건 2000년대입니다.
하이퍼텍스트를 전송하기 위해 사용되는 웹 프로토콜인 HTTP는 정보를 텍스트로 주고 받기 때문에 네트워크에서 전송 신호를 인터셉트 하는 경우 원하지 않는 데이터 유출이 발생할 수 있다는 취약점이 있었습니다. 이것을 해결하기 위해 Secure Socket이 추가된게 HTTPS입니다.
HTTP = HyperText Transfer Protocol
HTTPS = HyperText Transfer Protocol Secure Socket
HTTPS는 SSL이나 TLS 프로토콜을 통해 세션 데이터를 '암호화'하며, 기본 TCP/IP 포트는 443이고, SSL 프로토콜 위에서 HTTPS 프로토콜이 동작하므로 CA에서 '인증서를 발급'받아야 사용할 수 있습니다.
https의 암호화 방식
공개키 암호화 방식과 공개키의 느리다는 단점을 보완한
대칭키 암호화 방식을 함께 사용합니다.
- 인터넷 사이트(서버)는 공개키와 개인키를 만든 후, 신뢰할 수 있는 인증 기관(CA)에 자신의 정보와 공개키를 관리해 달라고 계약하고 (경우에 따라) 돈을 지불합니다.
이 때, 계약을 완료한 인증 기관은 기관만의 공개키와 개인키가 있습니다 - 인증 기관은 사이트가 제출한 데이터를 검증하고, 인증 기관의 개인키로 사이트에서 제출한 정보를 암호화해서 '인증서'를 만들어 제공합니다. 사이트는 인증서를 가지게 되었습니다.
- 인증 기관은 웹 브라우저에게 자신의 공개키를 제공합니다.
4, 사용자가 사이트에 접속하면 서버는 자신의 인증서를 웹 브라우저(클라이언트)에게 보냅니다. 예를 들어, 웹 브라우저가 index.html 파일을 달라고 요청했다면, 서버의 정보를 인증 기관의 개인키로 암호화한 인증서를 받게 됩니다.
- 웹 브라우저는 3에서 미리 알고 있던 인증기관의 공개키로 인증서를 해독하여 검증합니다. 그러면 사이트의 정보와 서버의 공개키를 알 수 있게 됩니다.
- 이 부분은 보안상의 의미는 없고, 해당 서버로부터 온 응답임을 확신할 수 있게 해주는 역할입니다.
- 이렇게 얻은 서버의 공개키로 대칭키를 암호화해서 다시 사이트에 보냅니다.
사이트는 개인키로 암호문을 해독하여 대칭키를 얻게 되고, 이제 대칭키로 데이터를 주고받을 수 있게 됩니다.
TCP/UDP
TCP : Transmission Control Protocol의 약자. 상호 통신이 이루어지기 때문에 신뢰성이 요구되는 애플리케이션에서는 TCP를 사용합니다.
TCP는 통신할 컴퓨터끼리 ‘보냈습니다’, ‘도착했습니다’라고 서로 확인 메시지를 보내면서 데이터를 주고받음으로써 통신의 신뢰성을 높인다. 웹이나 메일, 파일 공유 등과 같이 '데이터를 누락시키고 싶지 않은 서비스'에 사용합니다.
연결지향형, 바이트 스트림을 통한 연결, 혼잡제어/흐름제어, 순서보장-상대적으로 느림, 신뢰성 있는 데이터 전송(안정적), 세그먼트 TCP 패킷, HTTP/Email/File-transfer
UDP : User Datagram Protocol의 약자. 일방적이어서 간단한 데이터를 빠른 속도로 전송하고자 하는 애플리케이션에서 사용합니다.
UDP는 데이터를 보내면 그것으로 끝이므로 신뢰성은 없지만 확인 응답과 같은 절차를 생략할 수 있으므로 통신의 신속성을 높일 수 있습니다. VoIP(Voice over IP)나 시간 동기, 이름 해결 등과 같이 '무엇보다 속도를 필요로 하는 서비스'는 UDP를 사용합니다.
비연결지향형, 메세지 스트림을 통한 연결, 혼잡제어나 흐름제어 지원 X, 순서 보장되지 않음/상대적으로 빠름, 데이터 전송 보장 X, 데이터그램 UDP패킷, 도메인/실시간 동영상 서비스.
TCP 3-way-handshake
SYN
SYN+ACK
SYN
3 Way-Handshake :
TCP에서 통신을 하는 장치간에 서로 연결이 잘 되어있는지 확인하는 과정, 방법
SYN : synchronize sequence numbers (랜덤넘버)
ACK : acknowledgements (랜덤넘버에 1을 더한등의 답장넘버)
[STEP 1]
A클라이언트는 B서버에 접속을 요청하는 SYN 패킷을 보냅니다. 이때 A클라이언트는 SYN 을 보내고 SYN/ACK 응답을 기다리는 SYN_SENT 상태가 됩니다.
[STEP 2]
이때 B서버는 Listen 상태로 포트 서비스가 가능한 상태여야 하며, B서버는 SYN요청을 받고 A클라이언트에게 요청을 수락한다는 ACK 와 SYN flag 가 설정된 패킷을 발송합니다. 그리고 A클라이언트가 다시 ACK으로 응답하기를 기다리며 SYN_RECEIVED 상태가 됩니다
[STEP 3]
A클라이언트가 B서버에게 ACK을 보내고 이후로부터는 연결이 이루어지고 데이터가 오갈 수 있게 됩니다. 그리고 비로소 B서버가 ESTABLISHED 상태에 들어서는데
위와 같은 방식으로 통신하는것이 신뢰성 있는 연결을 위한 TCP의 3 Way handshake 방식입니다.
알면 좋은 토막상식
- 3way handshaking의 취약점을 이용해 서버를 공격 하는 방법이 있는데
이를 SYN Flooding 이라고 합니다.
3way handshaking STEP2 에서 (클라이언트로 부터 요청을 받고 응답을 하고난후 다시 클라이언트의 응답을 기다리는 상태) 연결을 메모리 공간인 백로그큐(Backlog Queue) 에 저장한 후 클라이언트의 응답 = STEP3을 기다리게 되는데...
이때 일정 시간 (default 로 UNIX/LINUX : 60초 , Windows : 256초 , Apache : 300 초이며 수정 가능) 동안 응답이 안오면 연결을 초기화합니다.
바로 이 점을 이용한 공격법인데요,
해커가 실제로 존재하지 않는 클라이언트IP로 응답이 없는 연결을 초기화 하기 전에 또 새로운 연결, 즉 1단계 요청만 무수히 많이 보내어 백로그 큐를 포화 상태로 만들어 다른 사용자들로부터 더 이상의 연결 요청을 못 받게 하는 공격 방법입니다.
대응책으로는 연결 타이머 시간을 짧게 하거나 백로그 큐 사이즈를 늘리는법, 정해진 시간 동안 들어오는 연결 요구의 수를 제한하는 법, 쿠키를 이용해서 전체 연결이 설정되기 전까지는 자원의 할당을 연기하는 법 등이 있습니다.
