OSI 7계층
7계층은 왜 나눌까?
•
통신이 일어나는 과정을 단계별로 알 수 있고, 특정한 곳에 이상이 생기면 그 단계만 수정할 수 있기 때문이다.
1. 물리(Physical)
리피터, 케이블, 허브 등
데이터를 전기적인 신호로 변환해서 주고받는 기능을 진행하는 공간.
즉, 데이터를 전송하는 역할만 진행한다.
2. 데이터 링크(Data Link)
브릿지, 스위치 등
물리 계층으로 송수신되는 정보를 관리하여 안전하게 전달되도록 도와주는 역할 수행.
Mac 주소를 통해 통신한다. 프레임에 Mac 주소를 부여하고 에러검출, 재전송, 흐름제어를 진행한다.
3. 네트워크(Network)
라우터, IP
데이터를 목적지까지 가장 안전하고 빠르게 전달하는 기능을 담당한다.
라우터를 통해 이동할 경로를 선택하여 IP 주소를 지정하고, 해당 경로에 따라 패킷을 전달해준다.
라우팅, 흐름 제어, 오류 제어, 세그멘테이션 등을 수행한다.
4. 전송(Transport)
TCP, UDP
TCP와 UDP 프로토콜을 통해 통신을 활성화한다. 포트를 열어두고,
프로그램들이 전송을 할 수 있도록 제공해준다.
•
TCP: 신뢰성, 연결지향적
•
UPD: 비신뢰성, 비연결성, 실시간
5. 세션(Session)
API, Socket
데이터가 통신하기 위한 논리적 연결을 담당한다. TCP/IP 세션을 만들고 없애는 책임을 지니고 있다.
6. 표현(Presentation)
JPEG, MPEG 등
데이터 표현에 대한 독립성을 제공하고 암호화하는 역할을 한다.
파일 인코딩, 명령어를 포장, 압축, 암호화한다.
7. 응용(Application)
HTTP, FTP, DNS 등
최종 목적지로, 응용 프로세스와 직접 관계하여 일반적인 응용 서비스를 수행한다.
사용자 인터페이스, 전자우편, 데이터베이스 관리 등의 서비스를 제공한다.
DNS(Domain Name Server)
모든 통신은 IP를 기반으로 연결된다. 하지만 사용자에게 일일이 IP 주소를 입력하는 건 좋지 않다.
이런 배경에서 DNS가 등장하였으며, DNS는 IP 주소와 도메인 주소를 매핑하는 역할을 한다.
도메인 주소가 IP로 변환되는 과정
1.
디바이스는 hosts 파일을 열어 본다.
a.
hosts 파일에는 로컬에서 직접 설정한 호스트 이름과 IP 주소를 매핑하고 있다.
2.
DNS는 캐시를 확인한다.
a.
기존에 접속했던 사이트의 경우 캐시에 남아있을 수 있다.
b.
DNS는 브라우저 캐시, 로컬 캐시(OS 캐시), 라우터 캐시, ISP(Internet Service Provider) 캐시 순으로 확인한다.
3.
DNS는 Root DNS에 요청을 보낸다.
a.
모든 DNS에는 Root DNS의 주소가 포함되어 있다.
b.
이를 통해 Root DNS에게 질의를 보내게 된다.
c.
Root DNS는 도메인 주소의 최상위 계층을 확인하여 TLD(Top Level DNS)의 주소를 반환한다.
4.
DNS는 TLD에 요청을 보낸다.
a.
Root DNS로부터 반환받은 주소를 통해 요청을 보낸다.
b.
TLD는 도메인에 권한이 있는 Authoritative DNS의 주소를 반환한다.
5.
DNS는 Authoritative DNS에 요청을 보낸다.
a.
도메인 이름에 대한 IP 주소를 반환한다.
이때 요청을 보내는 DNS의 경우 재귀적으로 요청을 보내기 때문에 DNS 리쿼서라 지칭 하고 요청을 받는 DNS를 네임서버라 지칭 합니다
HTTP & HTTPS
HTTP(HyperText Transfer Protocol)
•
인터넷 상에서 클라이언트와 서버가 자원을 주고 받을 때 쓰는 통신 규약
•
HTTP는 텍스트 교환이므로, 누군가 네트워크에서 신호를 가로채면 내용이 노출되는
보안 이슈가 존재한다.
•
이런 보안 문제를 해결해주는 프로토콜이 ‘HTTPS’
HTTP의 보안 취약점
•
도청이 가능하다
◦
평문으로 통신하기 때문에 도청이 가능하다.
◦
이를 해결하려면 통신자체를 암호화(HTTPS)하거나 데이터를 암호화 하는 방법이 있다.
◦
데이터를 암호화 하는 경우 수신측에서는 보호화 과정이 필요하다.
•
위장이 가능하다
◦
통신 상대를 확인하지 않기 때문에 위장된 상대와 통신할 수 있다.
◦
HTTPS는 CA 인증서를 통해 인증된 상대와 통신이 가능하다.
•
변조가 가능하다
◦
완전성을 보장하지 않기 때문에 변조가 가능하다.
◦
HTTPS는 메시지 인증 코드(MAC), 전자 서명 등을 통해 변조를 방지한다.
HTTPS(HyperText Transfer Protocol Secure)
•
인터넷 상에서 정보를 암호화하는 SSL 프로토콜을 사용해 클라이언트와 서버가 자원을 주고 받을 때 쓰는 통신 규약
•
HTTPS는 텍스트를 암호화한다.
◦
공개키 암호화 방식으로!
HTTPS 통신 흐름
1.
애플리케이션 서버(A)를 만드는 기업은 HTTPS를 적용하기 위해 공개키와 개인키를 만든다.
2.
신뢰할 수 있는 CA 기업을 선택하고, 그 기업에게 내 공개키 관리를 부탁하며 계약을 한다.
CA란?
- Certificate Authority로, 공개키를 저장해주는 신뢰성이 검증된 민간기업
Plain Text
복사
3.
계약 완료된 CA 기업은 해당 기업의 이름, A 서버 공개키, 공개키 암호화 방법을 담은 인증서를 만들고, 해당 인증서를 CA 기업의 개인키로 암호화해서 A 서버에게 제공한다.
4.
A 서버는 암호화된 인증서를 갖게 되었다. 이제 A 서버는 A 서버의 공개키로 암호화된 HTTPS 요청이 아닌 요청이 오게 되면, 이 암호화된 인증서를 클라이언트에게 건네준다.
5.
클라이언트가 main.html 파일을 달라고 A 서버에게 요청했다고 가정하자. HTTPS 요청이 아니기 때문에 CA 기업이 A서버의 정보를 CA 기업의 개인키로 암호화한 인증서를 받게 된다. CA 기업의 공개키는 브라우저가 이미 알고있다. (세계적으로 신뢰할 수 있는 기업으로 등록되어 있기 때문에, 브라우저가 인증서를 탐색하여 해독이 가능한 것)
6.
브라우저가 해독한 후에 A 서버의 공개키를 얻게 된다.
7.
클라이언트가 A 서버와 HandShaking 과정에서 주고 받은 난수를 조합하여 pre-master-secret-key 를 생성한 뒤, A 서버의 공개키로 해당 대칭키를 암호화하여 서버로 보낸다.
8.
A 서버는 암호화된 대칭키를 자신의 개인키로 복호화 하여 클라이언트와 동일한 대칭키를 획득한다.
9.
클라이언트, 서버는 각각 pre-master-secret-key를 master-secret-key 로 만든다.
10.
master-secret-key 를 통해 session-key 를 생성하고 이를 이용하여 대칭키 방식으로 통신한다.
11.
각 통신이 종료될 때마다 session-key를 파기한다.
HTTPS도 무조건 안전한 것은 아니다. (ex. 신뢰받는 CA 기업이 아닌 자체 인증서 발급한 경우)
이때는 HTTPS지만 브라우저에서 주의 요함, 안전하지 않은 사이트 와 같은 알림으로 주의를 받게 된다.