TCP/IP (6) 어플리케이션 계층

 

Application Layer

 

애플리케이션으로써 처리를 수행한다.

이전의 계층들은 모두 전송하는 과정이였다면 패킷을 실제 처리하는 것은 애플리케이션 계층이다.

 

 

1. HTTP

 

1-1. HTTP의 발전

 

(1) HTTP/0.9 (1991)

텍스트 파일을 다운로드하는 것만 가능했다.

헤더, 바디 등이 존재하지 않았다.

텍스트 파일을 서버에서 다운로드하기 위한 목적으로 만들어졌다.

 

(2) HTTP/1.0

메시지 포맷이 책정되었다.

다양한 파일 전송 기능이 생겨났으며, 이를 다운로드/업로드할 수 있었다.

텍스트 파일 이외에도 다양한 파일을 다룰 수 있게 되어 프로토콜로써 폭이 넓어졌다.

이때까지는 TCP 커넥션을 만들고 부수는 순서를 매번 반복했다.

 

(3) HTTP/1.1

파이프라인 기능이 추가되었다.

Keep-Alive 기능이 추가되었다.

 

Keep-Alive?

한 번 만들어진 TCP 커넥션을 재사용하는 기능이다.

HTTP/1.0까지는 확장 기능으로 존재했으나 HTTP/1.1에서는 표준 기능으로 존재하게 되었다.

RTT(Round-Tip Time)이 짧아져 처리량이 증가한다.

 

Pipe-line?

요청에 대한 응답을 기다리지 않고 다음 요청을 송신하는 기능이다.

HTTP 1.0까지는 매번 응답을 기다렸는데, 이 부분을 개선하는 것이 목적이였다.

그러나 실제로는 HTTP/1.1의 스펙은 같은 커넥션 안에서 응답 요청 교환을 병렬처리할 수 없는 사양이여서 별다른 성과가 없었다.

서버가 최초의 응답 요청 시간 걸려서 돌려주지 못하면, 이어진 요청에 대한 응답도 반환되지 않고 서버의 버퍼만 쓸데없이 소비하게된 것이다.

이를 HOL(Head of Locking Block)이라고 부르며, 오히려 악영향만 있어서 대부분의 브라우저에서 파이프라인은 비활성화되었다.

 

(4) HTTP/2

바이너리 형식 통신으로 변경되었다.

멀티플렉싱 기능 추가, 헤더 압축, 서버 푸시 등의 기능이 추가되었다.

구글의 SPDY 프로토콜을 기반으로 2015년 RFC7540에서 표준화되었다.

텍스트 형식의 메시지 단위로 교환하는 어플리케이션 데이터를 프레임(frame)이라는 바이너리 형식 단위로 교환해 오버헤드를 줄이고 성능이 향상되었다.

 

HPACK?

HTTP 헤더를 압축하는 기능이다.

HTTP/1.1은 같은 내용의 헤더를 수차례 교환하여 낭비가 심했으나 HTTP/2는 자주 사용하는 HTTP 헤더 이름이나 헤더를 미리 정적으로 결정한 숫자로 치환하거나, 혹은 한 번 송신한 헤더를 동적으로 할당한 숫자로 치환하는 등의 기능이다.

 

서버 푸시?

하나의 요청에 대해 여러 응답을 반환하는 기능이다.

HTTP/2 서버는 클라이언트가 최초로 요청한 콘텐츠를 해석하고, 다음에 올 요청에 대한 응답을 요청 전에 보낸다.

브라우저는 해당 응답을 미리 캐시해놓고 요청에 대한 응답을 캐시 영역에서 호출하여 성능 향상을 노린다.

ex> index.html과 함께 script.js style.css도 요청이 오지 않아도 미리 보낸다.

 

(5) HTTP/3

구글의 QUIC(Quick UDP Internet Connections) 기반으로 만들어졌으며 2022년 6월 6일 RFC9114로 표준화되었다.

UDP/TLS 1.3으로 성능이 향상되었다.

3way handshake를 스킵하고 SSL Handshake 시간을 줄여 애플리케이션 데이터를 보내지 않는 시간을 극단적으로 줄였다.

 

 

1-2. HTTP/1.1 메시지 포맷

 

(1) Request Message Format

 

 

- Request Line

클라이언트가 서버에 처리를 요청하기 위한 행.

리퀘스트 종류를 나타내는 메서드와 리소스 식별자를 나타내는 request uri, HTTP version의 세가지로 구성된다.

 

- Request URI

서버의 장소, 파일 이름, 파라미터 등 리소스를 식별하기 위해 사용하는 문자열로 RFC3986으로 규격화되었다.

리소스에 액세스하기 위해 필요한 정보를 모두 기술하는 절대 URI와 상대적인 위치를 나타내는 상대 URI가 존재한다.

절대 URI는 스킵 이름부터 프래그먼트 식별자까지 모두 구성된 것이며, 상대 URI는 기준이 되는 주소를 기준으로하는 상대적인 위치로 대부분 상대 URI를 사용한다.

 

(2) Response Message Format

 

- Status Line

웹 서버가 웹 브라우저에 대한 처리 결과의 개요를 반환하는 행이다.

HTTP 버전, 스테이터스 코드, reason phrase로 구성되어 있다.

 

 

 

 

1-3. HTTP 헤더의 종류

 

(1) request header

 

- Accept

웹브라우저가 처리할 수 있는 파일의 종류(MIME type, media type)과 우선도를 전달하기 위해 사용되는 헤더이다.

웹서버는 해당 정보를 기반으로 자원을 반환하며, 대응하는 자원이 없는 경우 406 Not Acceptable을 반환한다.

 

 

- Host header

HTTP/1.1에서 강제되는 필수 항목.

리퀘스트하는 웹 서버의 도메인 이름과 포트 번호가 설정된다.

 

- Referer

직전 연결 소스의 URI를 나타내는 헤더

주로 방문 기록 분석에 사용된다.

 

- User-Agent

웹 브라우저나 OS 등 사용자의 환경을 나타내는 헤더.

사용자 정보 분석에 주로 이용된다.

 

(2) Response header

리스폰스 메세지를 제어하기 위한 헤더이다.

 

- Etag (Entity tag)

리소스가 바뀌었는지 확인하는 식별자.

특정 리소스가 변경되면 entity tag를 업데이트하고, 클라이언트가 해당 리소스를 이미 가지고 이다면 304 Not Modified를 전송해 재전송하지 않도록 한다.

 

- Location header

리다이렉트 위치를 알리기위해 사용하는 해더를 의미한다.

300번대 스테이터스 코드와 조합하여 사용하며, 리다이렉트 대상지의 URI가 설정되어 있다.

 

- Server header

웹 서버의 OS나 버전, 소프트웨어가 설정되어 있다.

그러나 보안에 문제가 될 수 있어 대부분 서버 헤더는 비활성화 한다.

 

(3) Generic header

리퀘스트, 리스폰스 메세지 모두에서 범용으로 사용하는 헤더.

 

- Cache-Control header

웹 브라우저나 서버의 캐시를 제어하는 것에 사용한다.

웹 브라우저에 저장되는 프라이빗 캐시와 프록시 서버 혹은 CDN에 저장되는 공유 캐시가 존재한다.

 

- Connection header/ keep-alive header

둘 다 Keep-Alive를 제어하는 헤더이다.

리퀘스트가 오지 않았을 때의 timeout 시간이나 TCP 커넥션에 대한 잔여 리퀘스트 수 등에 대한 정보를 전달하고, Connection 헤더에 close가 설정되면 TCP 커넥션을 닫는다.

 

(4) Entity header

리퀘스트 메시지 및 리스폰스 메세지에 포함되는 메세지 바디에 관한 제어 정보를 포함하는 헤더이다.

 

- Content-Encoding/ Accept-Encoding

웹 브라우저가 처리할 수 있는 메세지 바디의 압축 방식을 지정한다.

주로 사용하는 방식은 gzip, compress, identify이다.

웹 브라우저는 자신이 대응하는 형식을 Accept-Encoding 헤더에 설정해 리퀘스트하고 서버는 그중에서 압축 방식을 택하고 해당 방식을 Content-Encoding 헤더에 설정한 뒤 응답한다.

 

- Content-Length

HTTP/1.1부터는 Keep-Alive가 있기 때문에 TCP가 반드시 close된다고 할 수 없다.

그래서 Content-Length 헤더로 메세지 경계를 전달하고, 적절한 횟수만 통신하고 커넥션이 close되도록 한다.

 

(6) 기타 헤더

 

- Set-Cookie/Cookie

HTTP 헤더와의 통신에서 특정한 정보를 브라우저에 저장시키는 구조 및 저장한 파일을 의미한다.

브라우저상에서 도메인별로 관리된다.

 

- X-Forwarded-For

부하 분산 장치에서 송신지 IP 주소가 변경되는 환경에서 변환 전의 송신지 IP 주소를 저장하는 헤더.

부하 분산 장치 사용 시 송신지 주소를 NAPT하면 해당 헤더를 통해 이전 주소를 알 수 있다.

AWS의 부하 분산장치인 ELB(Elastic Load Balancing)이나 ALB(Application Load Balancer)도 마찬가지이다.

 

- X-Forwarded-Proto

X-Forwarded-For의 프로토콜 버전이다.

부하 분산 장치에서 프로토콜이 변화되는 환경에서 변환 전 프로토콜을 저장한다.

처리 부하가 되기 쉬운 SSL 처리를 서버에서 대신하는 SSL Acceleration라는 기능을 사용할 경우 HTTPS를 로드 밸런서가 HTTP로 복호화하기 때문에 서버는 원래 프로토콜을 알 수 없게 된다. 따라서 이런 경우에 X-Forwarded-Proto를 사용한다.

 

- Message Body

HTML 데이터, 이미지, 동영상 파일 등 실제 보내는 애플리케이션 데이터가 들어있는 필드를 의미한다.

 

 

 

1-4. HTTP/2 포맷

메시지 헤더를 HEADERS frame에, 메세지 바디를 DATA frame에 각각 분할해서 저장하고 바이너리 형식의 프레임 단위로 스트림에 보낸다.

그리고 식별하는 Stream ID를 부여하여 어떤 스트림에 프레임을 보내는지 지정한다.

바이너리 형식이므로 컴퓨가 변환처리할 필요가 없어서 성능이 향상되었다.

 

 

 

 

(1) Request Line, Status Line

- Request Line

HTTP/1.1과 달리 메서드를 :method 헤더, 리퀘스트 URI를 :path 헤더, HTTP 버전을 :version 헤더에 각각 저장한 뒤 HEADERS 프레임으로 송신한다.

 

- Statusline

마찬가지로 기존의 1행에 담던 정보를 나눠서 HTTP 버전을 :version 헤더, 스테이터스 코드를 :status 헤더에 저장한 뒤 HEADERS 프레임으로 송신한다.

 

(2) Protocol Upgrade

HTTP1.1과 HTTP/2는 호환성이 없으며, HTTP/2로 연결하기 위해서는 별도의 순서가 필요하다.

 

- SSL Handshake

HTTP/2로 연결 시 ALPN(Application-Layer Protocol Negotiation)이라는 기능으로 서로 HTTP/2에 대응하는 것을 확인한 뒤 접속한다.

 

- HTTP 헤더 패턴

SSL/TLS로 암호화 통신을 사용하지 않을 때는 Upgrade Header를 붙여 HTTP/2 대응 여불르 서버에 알리고, 서버 또한 해당 헤더를 덧붙인 뒤 101 Switching Protocol 스테이터스 코드를 반환하고 HTTP2 서버로 이행한다.

반대로 서버에서 클라이언트에 이행을 제안하는 것도 가능하다.

 

- Direct Connection

클라이언트와 서버가 함꼐 HTTP/2로 연결할 수 있음을 알고 있는 검증 환경에서 사용하는 것으로, 어떤 준비 과정 없이 HTTP/2로 연결한다.

 

 

 

1-5. 부하분산장치(Load Balancer)

각각 네트워크 계층(IP 주소) 트랜스포트 계층(포트 번호), 애플리케이션 계층(메시지)의 정보를 이용해 여러 서버에 커넥션을 할당하는 기능이다.

 

(1) 수신지 NAT

패키지 수신지 IP 주소를 변환하는 기술.

클라이언트로 패킷을 받으면 서버의 상태와 커넥션 상태를 확인한 뒤 최적의 IP 주소로 수신지 IP를 변환한다.

커넥션 테이블 정보를 기반으로 수행하며, 부하 분산 장치는 송신지/가상/서버 IP 주소와 포트 번호를 각각 저장하고, 프로토콜 등의 정보를 커넥션 테이블로 관리하여 어떤 커넥션을 어느 IP 주소에 수신지 NAT할 것인지 파악한다.

 

- 부하분산장치가 가상 서버로 클라이언트의 커넥션을 받는다. 수신지 IP 주소는 가상 IP 주소(Virtual IP Address)이다.

받은 커넥션은 커넥션 테이블로 관리된다.

- 부하분산장치는 가상 IP 주소로 된 수신지 주소를 부하 분산 대상 서버 IP 주소로 변경한다, 변환한 IP 주소를 서버 상태/ 커넥션 상태 등에 따라 동적으로 커넥션이 분산된다.

변환한 IP 주소도 기존과 함께 관리된다.

- 커넥션을 받은 서버가 어플리케이션 처리 이후 default gateway(부하분산장치)로 반환을 보낸다.

 

(2) Health Check

서버에 대해 정기적으로 감시 패킷을 보내 가동 여부를 감시하고, 중단이라고 판단하면 해당 서버를 부하 분산 대상에서 제외한다.

L3, L4, L7체크로 나뉘며 레이어가 높아질수록 세밀한 컨트롤이 가능하나 부하가 증가한다.

 

(3) 부하 분산 방식

- 정적 부하 방식 : 서버의 상황과 관계 없이 미리 정의된 설정에 따라 분배할 서버를 정하는 방식으로, 순서대로 할당하는 라운드 로빈과 미리 정해둔 비율에 기반해 할당하는 비율 방식 등이 있다.

- 동적 부하 방식 : 서버 상황에 맞춰 할당할 서버를 결정하는 방식이다. 최소 커넥션 수/ 최단 응답시간 등 다양한 알고리즘을 사용한다.

 

(4) 옵션 기능

현재 로드 밸런서는 트랜스포트 계층이 아닌 애플리케이션 계층까지 관여하여 ADC(Application Delivery Control)이라고도 부른다.

 

- persistence

애플리케이션의 같은 세션을 같은 서버에 계속 할당하는 기능으로, 일련의 처리를 동일한 서버에서 수행해야 정합성을 얻을 수 있는 경우 특정 정보를 기반으로 같은 서버에 계속 할당한다.

IP 주소 방식 : 클라이언트 IP 주소를 기반으로 같은 서버에 계속해서 할당하는 방식, NAPT 환경이나 프록시 환경 등 여러 클라이언트가 송신지 IP 주솔르 경유하는 경우에는 같은 서버에 세션이 집중되어버린다는 단점이 있으나 사용하기 쉬워 IP 주소가 개별적으로 관리될 확률이 높은 서버에서 주로 사용한다.

Cookie 방식 : 최초의 리퀘스트에 대한 리스폰스에 서버 정보를 포함한 Cookie를 삽입하여 다음 리퀘스트에는 해당 Cookie 정보를 기반으로 서버를 할당한다. 처리 부하가 증가한다는 단점이 있으나 NAPT 환경이나 프록시 환경에서도 더욱 유연하게 부하를 분산한다.

 

- Application Switching

Request URI, 웹 브라우저 종류 등 애플리케이션 데이터에 포함된 다양한 정보를 기반으로 더 세세하고 폭넓은 부하 분산을 수행한다.

 

- HTTP/2 오프로드

서버가 수행할 처리를 대신하는 기능으로 서버를 HTTP/2로 업그레이드하지 않아도 부하분산장치는 HTTP/2로 통신을 이행한다.

 

 

 

 

2. Secure Socket Layer, Transport Layer Security (SSL, TSL)

 

2-1. SSL이란

 

(1) SSL의 의의

 

- 암호화를 통한 도청 방지

정해진 규칙에 기반하여 데이터를 변환하고, 제 3자가 데이터를 엿보는 도청을 방지한다.

 

- 해시화를 통한 변조 방지

애플리케이션 데이터로부터 정해진 계산(해시)에 기반해 고정된 길이 데이터를 추출하여 애플리케이션 데이터가 바뀌면 해시값도 바뀌므로 변조를 감지할 수 있다.

SSL은 데이터 변조 여부를 파악하기 위해 데이터와 해시값을 함께 전송한다.

수신한 단말은 데이터로부터 얻은 해시값과 함꼐 전송된 해시값을 비교하여 변조 여부를 파악한다.

 

- 디지털 인증서를 통한 신분 위조 방지

신뢰할 수 있는 제 3자 기관(CA)의 디지털 서명을 기준으로 단말의 신뢰성을 판단한다.

 

(2) SSL의 암호화 방식

 

- 공통키 암호화 방식 (대칭키)

암호화 키와 복호화 키로 동일한 키를 사용하는 방식을 의미한다.

클라이언트와 서버가 미리 같은 키를 공유하고, 암호화키로 암호화한 뒤 같은 키로 복호화한다.

 

스트림 암호는 1비트 단위로 암호화처리하는 암호화 방식이나 RC4에 취약성이 발견되어 사용하지 않는다.

블록 암호는 일정 비트수 단위로 구분해 하나하나 암호화처리를 적용해 시간은 걸리나 신뢰성 높은 암호화 방식인 AES를 사용하여 대부분 이 방식을 채택한다.

상대적으로 처리 속도가 빠르고 부하가 적다는 장점이 있다.

 

- 공개키 암호화 방식 (비대칭키)

암호화키와 복호화키로 다른 키를 사용하는 방식으로 비대칭키 방식이라고도 부른다.

RSA, DH/DHE, ECDH/ECHDE가 해당 방식을 사용한다.

공개키와 비밀키로 구성되며, 이 두 키는 Key pair라고 불린다.

키 페어는 수학적인 관계로 성립하여 한 쪽 키에서 다른 키를 도출할 수 없다.

 

키 전송에 신경쓰지 않아도 된다는 장점이 있으나 암호화 방식의 처리가 복잡하여 암호화/복호화 시간이 오래 걸려 부하가 크고 시간이 오래 걸린다.

 

- 하이브리드 암호화 방식

SSL에서 채택하는 방식으로 공개키 암호화로 먼저 서로 공유해야하는 공통키의 재료를 공유하고, 이후 각자의 데이터로 공통키를 만들어 데이터를 암호화한다.

 

(3) SSL 해시 함수

 

- 왜 해시를 사용하는가?

데이터가 1비트라도 다르면 해시값이 달라져서 변조를 감지할 수 있다.단방향 해시 함수 계산식은 고정적으로 데이터가 같으면 해시값도 항상 같다.해시값만 읽어서 원 데이터를 복원할 방법이 없어 탈취당해도 안전하다.데이터 크기와 관계 없이 해시값은 고정이므로 해당 성질을 이용해 일정 길이만 비교할 수 있으므로 처리 속도를 높이고 부하는 억제한다.

 

- 어플리케이션 데이터 검증 시전형적인 사용 방법으로 송신자가 애플리케이션 데이터와 해시값을 전송하고, 수신자는 애플리케이션 데이터로부터 해시값을 계산하고 전송된 해시값과 받은 해시값을 비교하여 변조 여부를 판단한다.또한 메세지 인증코드 (MAC, Message Authentication Code) 기술을 사용하여 어플레리케이션 데이터와 MAC 키를 섞어 MAC 값을 계산한다. 따라서 상대를 인증하는 용도로도 사용한다.

 

- 디지털 인증서 검증CA에서 해당 사이트를 인증할 때 디지털 인증을 해시화한다.디지털 인증서를 받은 수신자는 인증 기관의 공개키로 복호화하여 서버의 위/변조 여부를 파악한다.

 

 

 

2-2. SSL 버전

 

(1) SSL 2.0

1.0의 경우 출시 되기 이전에 취약성이 발견되여 폐기됐기 때문에 실제 사용된 것은 2.0이 처음이다.

1994년 출시되었으며 downgrade attack, version rollback attack 등 취약점이 발견되어 사용하지 않는다.

RFC6176에서 SSL 2.0 사용을 금지했다.

 

(2) SSL 3.0

1995년 출시되었으며 오랜 세월 사용되었으나 POODLE(Padding Oracle On Downgraded Legacy Encryption) 공격 이후 사용하지 않게 되었다.

RFC7568에서 폐지되었다.

 

(3) TSL 1.0

1999년 RFC2246에서 표준화되었다.

SSL3.0과 크게 다르지 않으나 POODLE 공격에 대응하고 AES/Caelia 같은 진보된 암호화 방식을 사용하였다.

20년 이상 사용되었으나 암호화/인증 방식이 노후화되어 2020년부터 주요 브라우저에서는 지원을 중단하였다.

 

(4) TLS 1.1

2006년에 출시되었으며 RFC4346에서 표준화되었다.

TLS1.0의 취약점인 BEAST(Browser Exploit Aganist SSL/TSL)에 대응하고 수출용 암호를 폐지하였다.

2020년 TSL1.0과 함께 주요 브라우저에서 지원이 중단되었다.

 

(5) TLS 1.2

RFC5246에서 2008년 표준화되었다.

SHA-2 해시 함수에 대응하고, GCM, CCM에 대응하여 안정성을 더 향상시켰다.

현재 주로 사용되고 있는 버전이다.

 

(6) TLS1.3

더욱 강력한 해시 함수와 암호화 방식으로 대응하여 안정성이 향상되었다.

SSL Handshake 프로세스를 간략화하여 성능을 향상했다.

 

 

 

2-3. SSL record Format

 

SSL record = SSL Header + SSL Payload

SSL header = content-type + protocol version + ssl paylod length

 

(1) Content type

SSL 레코드 종류를 나타내는 1바이트 필드.

핸드쉐이크 레코드, 암호사양 변경 레코드, 얼럿 레코드, 어플리케이션 데이터 레코드 4가지로 분류된다.

 

- 핸드쉐이크 레코드 : SSL Handshake에 사용하는 레코드

- 암호 사양 변경 레코드 : 핸드셰이크에 따라 결정된 사양을 확정하거나 변경하기 위해 사용한다.

- 얼럿 레코드 : SSL 관련 에러가 발생했음을 전달하는 레코드로, Alert Level이 Fatal인 경우 즉시 커넥션이 중단된다.

- 어플리케이션 데이터 레코드 : 실제 어플리케이션 데이터를 포함한 레코드

 

(2) SSL version

SSL record 버전을 나타내는 2바이트 필드.

상위 1바이트는 메이저, 하위 1바이트는 마이너 버전을 나타낸다.

 

(3) SSL 페이로드 길이

SSL 페이로드의 길이를 바이트 단위로 정의한 2바이트 필드.이론상 최대 65536바이트 레코드를 다룰 수 있으나 RFC6246에서는 16384 이하가 되도록 정의하고 있다.

 

 

2-4. SSL 흐름 (~1.2v)

 

(1) 서버 인증서 준비- HTTP 서버에서 비밀킬르 만든다.- 비밀키를 기반으로 CSR(Certificate Signing Request)를 만들어 인증 기관에 보낸다. 서명 전 인증서의 정보를 입력해 CSR을 만든다.- 인증기관이 다양한 여신 데이터 등의 정해진 프로세스에 기반해 신청자의 신원을 조회하고 조사 통과시 CSR을 해시화하여 인증기관의 비밀키로 암호화하고 디지털 서명으로 만들어 송신한다.- 인증 기관에서 받은 서버 인증서를 서버에 설치한다.

 

(2) SSL 핸드셰이크 사전 준비

 

첫 번째, Client Hello- TCP의 3way handshake 과정을 거친다.- 웹 브라우저가 사용할 수 있는 암호화 방식/ 단방향 해시 함수/ SSL 버전/ client random Number/ 시간/ 세션 id/ 압축 방식 등을 전달한다.

 

두 번째, Server Hello- 받은 암호 스위트 리스트와 자신의 암호 스위트 리스트를 참조하여 가장 보안성이 높은 암호화 방식을 택한다.- SSL 버전, Server random, CA인증서와 함꼐 Server Hello Done을 보낸다.

 

세 번째, 공통키 교환웹 브라우저가 인증서를 검토한 뒤 pre-master secret이라는 공통키 재료를 서버로 보낸다.웹 브라우저와 HTTP 서버는 pre-master secret과 Client Hello로 얻은 client random, 그리고 server random을 섞어 master secret을 만든다.이를 이용해 암호화에 사용할 세션키와 해시화에 사용할 MAC 키를 만들어 시그릿을 공개키로 암호화햐여 보낸다.서버키는 비밀키로 복호화하야 pre-master secret을 추출하고 client random과 server random을 이용해 같은 키를 만든다.

 

네 번째, 최종 확인서로 Change Chiper Spec과 Finished를 교환하여 결정한 사항을 확인하고 SSL 핸드셰이크를 종료한다. 이후 SSL 세션이 만들어진다.

 

다섯 번째, 인증 기관에서 받은 서버 인증서를 서버에 설치한다.

 

(3) 암호화 통신 : 애플리케이션 데이터를 MAC 키로 해시화한 뒤 세션키로 암호화하여 어플리케이션 데이터 레코드로 전송한다.

 

(4) SSL 세션 재이용 : SSL 핸드셰이크는 시간이 오래 걸리기 때문에 최초 SSL 핸드셰이크에서 생성한 세션 정보를 캐시하여 2번째 이후 재사용하는 SSL session resumption이라는 기능을 제공한다.

 

(5) SSL 세션 종료 : 종료하고 싶은 쪽에서 close_notify를 송출하고 TCP의 4way handshake 이후 커넥션을 종료한다.

 

 

 

2-5. 클라이언트 인증

미리 웹 브라우저에 설치한 클라이언트 인증거를 이용할 수 있다.

 

(1) 클라이언트 인증서 요청 단계는 이전과 같다.

 

(2) 클라이언트 인증서 전송

Certificate Request와 Server Hello Done을 받은 후 클라이언트에 설치되어 있던 인증서를 송신한다.

 

(3) 해시값 송부

클라이언트 인증서를 송신한 뒤 Client Key Exchange로 pre-master secret을 송신한다.

이후 Certificate Verify로 현재까지의 교환을 해시화하고 비밀키로 암호화한 뒤 디지털 서명으로 송신한다.

Certificate Verify를 송신받은 서버는 포함된 공개키를 복호화하고 해시값으로 변조 여부를 체크한 뒤 이후는 기존과 같다.

 

 

 

 

3. DNS (Domain Name System)

IP 주소와 도메인 이름을 상호 교환하여 사람이 이해하기 쉬운 형태로 통신할 수 있게 한다.

 

3-1. 도메인 이름

 

문자열 하나하나를 label이라고 부르며 점으로 구분된다. 도메인 이름은 FQDN(Fully Qualified Domain Name) 호스트 부분과 도메인 부분으로 구성된다.

호스트 부분은 가장 왼쪽 라벨로 컴퓨터 자체를 나타낸다.

도메인 부분은 TDL(Top Level Domain), Second Level Domain, Third Level Domain..으로 구성되어 있으며 국가 조직 기업 등을 나타낸다.

 

도메인 이름은 루트를 꼭짓점으로 탑 레벨 도메인부터 서브레벨 도메인까지 이어지는 트리 형태의 계층구조로 되어있으며, 이를 domain tree라고 한다.

 

3-2. name resoulution/ zone transfer

 

(1) name resolution

IP 주소와 도메인 이름을 서로 교환하는 과정을 의미한다.

 

- DNS 클라이언트

DNS 서버에 이름 결정을 요청하는 클라이언트 소프트웨어.

캐시 서버에 대해 이름 결정을 요청하며, 캐시 서버로부터 받은 응답 결과를 캐시해두고 같은 질문이 있을 때 재이용하여 트래픽을 억제한다.

 

- 캐시 서버

DNS 클라이언트로부터의 쿼리를 받아 네트워크상의 서버로 이름 결정을 송신하는 DNS 서버.

응답 결과를 일정 시간 캐시해두고 같은 질의가 있을 때 재이용하여 트래픽을 억제한다.

 

- 권위 서버

관리하는 도메인 범위에 관련된 정보를 데이터베이스에 리소스 레코드 형식으로 저장해놓는다.

캐시 서버는 도메인 이름의 라벨부터 재귀적으로 권위 서버에 반복 쿼리를 실행하며, 마지막까지 도달 시 권한 서버로부터 도메인 이름에 대응하는 IP 주소를 받는다.

 

(2) Zone Transfer

- 캐시 서버 다중화

DNS 클라이언트측의 설정으로, 프라이머리 DNS 서버와 세컨더리 DNS 서버를 지정해놓는다.

문의 대상지를 다수 설정함으로써 다중화하는 것.

 

- 권위 서버 다중화

프라이머리 서버가 중단되어도 세컨더리 DNS 서버로 같은 정보를 반환할 수 있도록 서버간에 zone file을 정기적으로 동기화한다.

 

 

 

3-4. DNS를 이용한 기능

 

(1) DNS 라운드 로빈

DNS를 이용한 부하 분산 기술로, 하나의 도메인에 여러 IP 주소를 등록해두면 DNS 쿼리를 받을 때마다 순서대로 다른 IP 주소를 반환한다.

부하분산장치 없이 서버의 부하 분산이 가능하다는 장점이 있으나 장애 내성이나 유연성은 부족하다.

 

(2) 광역 부하 분산(GSLB, Global Server Load Balancing)

 

지리적으로 떨어져있는 서버에 통신을 할당해 부하를 분산하는 기술.

부하 분산 장치 혹은 클라우드 서비스의 광여 부하 분산 기능이 권위 서버 역할을 하며 IP 주소를 반환한다.

각 서버의 상태를 감시하고 그 결과에 따라 응답하는 IP 주소를 바꿔 부하를 유연하게 분산한다.

부하 분산 목적보다 재난에 대한 대책으로 주요 사용된다.

 

(3) CDN (Cntent Delivery Network)

웹 콘텐츠를 대량 송신하기 위해 최적화된 인터넷 서버 네트워크.

오리지널 컨텐츠를 가진 origin server와 캐시를 가진 edge 서버로 구성된다.

사용자를 물리적으로 더 가까운 엣지 서버로 유도하기 위해 DNS를 사용한다.

 

권위 서버에서 CDN 권위 서버의 FQDN을 CNAME으로 등록해놓고 DNS 쿼리를 받으면 CNAME의 FQDN을 반환한다.

클라이언트는 CDN의 권위 서버에 DNS 쿼리를 송신하고, CDN의 권위 서버는 IP 주소를 기준으로 가장 가까운 엣지 서버의 IP 주소를 반환한다.

 

 

 

 

 

 

4. 메일 프로토콜

 

4-1. 메일 송신 프로토콜

메일 송신에는 SMTP(Simple Mail Transper Protocol)을 사용한다.

원형 그대로는 보안 문제가 많아서 기존 상태 그대로 사용하지 않는다.

 

(1) SMTP

RFC 5321로 표준화되었으며 TCP 25번을 사용해 통신한다.

메일 서버는 클라이언트로부터 메일을 받으면 @ 뒤에 기술된 FQDN을 보고 DNS 서버로 MX 레코드 (SMTP 서버 IP주소)를 문의한다.

DNS 서버에 의해 상대 메일 서버 IP 주소를 확인 후 해당 IP 주소로 메일을 송신한다.

수신측 메일 서버는 @ 앞에 기록된 사용자 이름을 기준으로 메일 박수를 나누고 메일을 저장한다.

이 시점에서 메일이 상대에게 아직 도착하지 않는다.

 

(2) 인증 기능

SMTP는 인증 기능이나 암호화 기능이 없다는 문제가 있어서 확장 기능을 이용해 보안 레벨을 향상시킨다.

 

- SMTP 인증

RFC4954에 표준화된 기능으로 TCP587을 사용한다.

메일 송신 전 사용자 이름과 비밀번호로 사용자를 체크하고 인증에 성공하면 메일을 받는다.

 

- POP before SMTP

POP을 이용한 사용자 인증 기능으로, 메일 송신 전 POP로 인증하고 수신 서버는 인증에 성공하면 일정 시간동안 해당 IP로부터 메일을 받는다.

 

- 암호화 기능은 주로 SMTPS(SMTP over SSL/TSL)을 사용한다.

최초에 서로가 SMTPS에 대응하고 있는 것을 STARTTLS로 확인한 후 SSL 핸드 셰이크로 인증/ 키 교환 후 암호화 처리한다.

 

 

4-2. 수신 프로토콜

 

(1) POP3

RFC1393으로 표준화된 프로토콜로 TCP 110번을 사용한다.

일 소프트웨어를 사용하는 PC가 메일 박스에 접속하면 POP3 서버에 메일을 요청하고, POP3 서버는 메일 소프트웨어에서 받은 사용자 이름과 비밀번호를 인증하고, 인증에 성공하면 메일을 추출해 메일 데이터를 전송한다.

 

RFC로 표준화된 오리지널 POP3는 인증 기능만 있고 암호화 기능은 없다.따라서 APOP(Authenticated Post Office Protocol)과 POS3S(POP3 over SSL/TSL)의 2가지 종류를 사용한다.APOP는 해시함수를 이용하는 것으로 보안 효과가 상대적으로 떨어지며, POP3S는 POP3를 SSL/TSL로 암호화하는 기능이라 상대적으로 보안레벨이 향상된다.

 

(2) IMAP4RFC3501로 표준화되었으며 TCP143번으로 통신한다.IMAP4는 메일을 메일 서버에 남긴채 메일 소프트웨어에서 열람하는 것이 POP3와 차이점이다.메일 서버에서 메일을 일괄 관리할 수 있으므로 PC, 태블릿, 스마트폰 등 여러 단말에서 동일하게 메일을 관리할 수 있다.

 

마찬가지로 암호화 기능은 따로 없어서 SSL/TSL을 이용해 IMAP4S로 확장하며 TCP 993번을 통신한다.

 

 

 

 

 

 

5. 관리 액세스 프로토콜

원격 네트워크에서 기기 정보를 확인하거나 설정할 때 사용하며 GUI, CLI가 존재한다.GUI에서는 HTTP/HTTPS, CLI에서는 Telnet/SSH(Secure Shell)을 사용한다.HTTP/HTTPS와 마찬가지로 Telnet/SSH도 암호화 여부의 차이이며 양 쪽 모두 거의 모든 상황에 HTTPS/SSH를 사용한다.

 

5-1. Telnet

RFC854에서 표준화된 프로토콜로 원시적이고 단순하다.L7 헤더가 없으면 L7 페이로드에 명령어나 ASCII 코드 텍스트 데이터를 그대로 저장한다.

 

Telnet 클라이언트는 Telnet 서버와 3way handshake 이후 이름과 비밀번호로 인증하고 데이터를 받는다.비밀번호를 포함한 모든 데이터가 암호화되지 않은 평문으로 교환되어 보안에 취약하다.

 

최근에는 보안상의 문제로 인해 Application 계층에 액세스하기보다는 트랜스포트 계층에서 ping을 사용하여 트러블 슈팅에 주로 사용한다.

 

5-2. SSH

RFC4253에 표준화된 프로토콜로 TCP22번을 사용한다.Telnet에 암호화와 공개키 인증, 메시지 인증 등의 기능을 추가한 것이다.도청 걱정이 없고 brute force 공격에도 비밀키가 유칠되지 않는한 로그인할 수 없다.

 

SSH 클라이언트와 SSH 서버는 액세스 시 3way handshake로 TCP 커넥션을 연다.이후 과정은 아래와 같다.

 

(1) 파라미터 교환대응하는 버전/ 암호화 방식/ 인증 방식 등을 리스트로 교환한다.(2) 키 공유DH 키 공유(공개키 방식)으로 공개키를 교환하고, 데이터 암호화에 사용할 공통키를 공유한다.(3) 사용자 인증접속하는 사용자가 올바른 사용자인지 인증하며 비밀번호 혹은 공개키로 인증한다.(4) 로그인사용자 인증이 끝나면 로그인이 완료되며 Telnet과 달리 제 3자가 도청할 수 없다.

 

5-3. 파일 전송

SCP(Secure Copy)와 SFTP(SSH File Transfer Protocol) 방식이 있다.네트워크 기기 소프트웨어 버전 업그레이드 시 업로드나 트러블 슈팅 시 로그파일/ 패킷 캡처파일 다운로드 등에 사용한다.

 

5-4. 포트포워딩

특정 포트 번호에 대한 통신을 SSH로 만든 암호화 통신로를 사용해서 다른 단말에 전송하는 기능이다.(1) SSH 클라이언트로부터 SSH 서버에 대해 SSH로 로그인하고 암호화 통신로를 만든다.(2) SSH 클라이언트에서 포트 포워드를 설정한다.해당 설정에서 로컬 포트가 Listen 상태가 된다.(3) 자기 자신의 로컬 포트에 액세스한다.(4) SSH 클라이언트 첫 번째에서 만든 암호화 통신로를 사용해 SSH 서버에 패킷을 전송한다.(5) SSH 서버는 리모트 주소(부하분산장치)의 리모트 포트에 대해 패킷을 전송한다.

 

 

 

6. 운용 관리 프로토콜

 

6-1. NTP (Network Time Protocol)네트워크 기기나 서버의 시각을 맞추는 프로토콜로 TFC7822로 표준화되었다.

 

 

Startum이라는 값을 이용한 계층구조로, Startum은 최상위 시각 생성지에서 얼만큼의 계층을 경유했는지 나타낸다.NTP 서버를 경유 시마다 카운트가 증가한다.

 

6-2. SNMP (Simple Network Management Protocol)네트워크 기기나 서버의 성능 감시, 장애 감시에 사용하는 프로토콜이다.CPU/메모리 사용률, 트래픽 양, 패킷 양 등 다양한 관리 대상 기기 정보를 정기적으로 수집한다.

 

- SNMP manager : 에이전트가 가진 관리 정보를 수집/감시하는 애플리케이션- SNMP agent : 관리자의 요청을 받아 장애를 알리거나 하는 프로그램.

 

6-3. Syslog네트워크 기기 및 서버의 로그를 전송하기 위한 프로토콜로 RFC3164, RFC5424로 표준화되었다.이벤트 발생 시 메모리 디스크에 저장함과 동시에 Syslog 서버로 전송한다.유니캐스트로 수행하며 주로 UDP 514 포트를 이용한다.

 

 

 

 

 

 

7. 다중화 프로토콜 (redundancy protocol)

 

7-1. 물리 계층의 다중화

(1) 링크 애그리게이션(LAG, Link Aggregation)

몇 개의 스위치 포트를 논리 포트로 그룹화하고 인접 스위치의 논리 포트와 접속해 논리 포트를 만든다.

평상시에는 모든 물리 링크로 프레임을 전송하여 대역을 확보하고, 링크에 장애가 발생했을 때는 장애 링크를 절단하고 우회하여 프레임을 계속 전송할 수 있다.

 

(2) 티밍(teaming)

여러 물리 NIC를 하나의 논리 NIC로 모으는 기술.

 

- 물리 환경 티밍 : OS 표준 기능으로 구현한다. 일반적으로 폴스 톨러런스(fault tolerance), 로드 밸런싱, 링크 애그리게이션이 있다.

 

- 가상 환경 티밍 : 가상화된 서버나 네트워크 기기의 경우 가상화 소프트웨어에서 동작하는 가상 스위치에 접속하고, 실제 연결된 물리 NIC를 경유해 네트워크에 접속한다.

주로 많이 사용되는 방식은 포트ID로 가상 스위치에 가상 머신 접속 시 포트 ID라는 식별자를 할당하고, 포트 ID별로 사용하는 물리 NIC를 선택하고 할당된 수만큼 대역을 확장한다.

 

(3) 스택

여러 스위치를 스택 케이블(stack cable)이나 광대역 LAN 케이블로 접속해 하나의 논리 기기로 모은다.

링크 애그리게이션과 조합해 전송 능력 확장, 혹은 네트워크 구성 단순화에 주로 사용한다.

 

 

7-2. 데이터링크 계층 다중화

(1) STP (Spanning-Tree Protocol)을 사용하며, 물리적으로 루프하는 네트워크의 포트를 막아 논리적으로 트리 구성을 만드는 프로토콜을 의미한다.

인접 스위치 사이에서 BDPU라는 이더넷 프레임을 주고 받으며 트리 구성 시작점이 되는 route bridge와 패킷을 보내지 않는 blocking port를 결정한다.

STP, RSTP, MSTP 3종류로 나뉜다.

 

(2) BPDU guard

이더넷에는 TTL 개념이 없으므로 BDPU가 필요하다.

STP를 활성화한 스위치의 포트는 트리 구성을 만드는 계산 수행 시까지 50초 시간이 소요되나 PC, 서버 접속 포트는 PostFast라는 설정을 수행해 접속과 동시에 패킷을 전송한다.

BDPU는 PostFast를 설정하는 포트에서 BDPU를 받아쓸 때 해당 포트는 강제로 다운시켜 루프 자체가 구성되지 못하도록 만든다.

 

 

 

7-3. 네트워크 계층 다중화

FHRP(First Hop Redundancy Protocol)을 사용한다.

서버나 PC의 첫번째 홉은 default gateway를 의미한다.

 

하나의 기본 게이트웨이를 가상적인 기본 게이트웨이와 같이 동작시켜 자동화하고 하트비트로 상태를 인식하고 액티브-스탠바이 방식으로 동작한다.

 

(1) 트래킹

액티브 기기와 스탠바이 기기는 생사감시 패킷에 포함된 우선도에 따라 결정되며, 최근에는 CPU 사용량, 메모리 사용률, 라우팅 테이블 정보 등까지 고려할 수 있다.

 

(2) 방화벽 다중화 기술

액티브 기기가 처리한 커넥션 정보를 스탠바이 기기에 동기화해 동일한 필터링 규칙을 담는다.

실시간으로 커넥션 정보나 설정 정보를 주고받으므로 대역을 많이 사용한다.

 

(3) 부하분산장치 다중화

퍼시스턴스 정보나 콘텐츠를 스탠바이 기기에 동기화하여 페일오버가 발생하더라도 정합성을 유지하도록 한다.

가장 많은 대역을 차지하는 방식으로 애플리케이션 동작과 CPU 부하 등을 고려하여 사용한다.

 

 

 

8. ALG 프로토콜 (Application Level Gateway)

고정된 포트 번호가 아닌 동적으로 변화하는 포트 번호를 방화벽이나 부하분산장치에서 처리하기 위한 기능

 

8-1. FTP File Transfer Protocol

파일 전송용 애플리케이션 프로토콜로 RFC959에서 표준화되었다.

암호화기능을 제공하지 않으나 여전히 많이 사용된다.

 

데이터 커넥션과 컨트롤 커넥션을 만들어 명령어를 송신하거나 결과를 반환한다.

액티브 모드의 경우 서버에서 클라이언트에게 커넥션을 만들며 패시브 모드는 클라이언트에서 서버에 대해 데이터 커넥션을 만든다.

 

8-2. TFTP(Trivial File Transfer Protocol)

UDP로 파일을 전송하기 위한 프로토콜로 RFC1350으로 표준화되었다.

인증 기능, 암호화 기능이 없으므로 인터넷 환경에서는 거의 사용하지 않는다.

그러나 프로그램 코드 자체가 작고 동작이 가벼워 네트워크 기기 펌웨어 업데이트 등에 사용된다.

 

8-3. SIP (Session Initiation Protocol)

IP 전화 호출을 제어하는 프로토콜로, SIP로 SIP 서버에 전화를 걸고 RTP(Real-Time Transport Protocol)이라는 별도 프로토콜로 Peer-To-Peer 음성이나 동영상을 주고 받는다.

RFC3261로 표준화되었으며 대부분 UDP를 사용한다.

 

(1) 전화 기동과 동시에 SIP 서버에 IP 주소나 전화번호를 등록한다.

(2) SIP 서버는 해당 정보를 데이터베이스에 저장한다.

(3) IP 전화 A가 IP 전화 B에 전화를 건다.

(4) SIP 서버는 데이터베이스에 B의 IP주소로 발신 메세지를 전송한다.

(5) IP 전화 B가 전화를 받는다. SIP 서버에 응담 에세지가 전송된다.

(6) SIP 서버는 응답 메세지를 IP 전화 A로 전달한다.

(7) 서로의 IP주소를 교환했으므로 RTP로 직접 데이터를 주고받는다.