안녕하세요.

오늘은 REST API에 대해서 포스팅 합니다.

REST 아키텍쳐를 웹 아키텍쳐중 하나인 HTTP 프로토콜과 동일 선상에서 해석하는 자료가 많았습니다.

재밌는 사실은 REST 창시자인 로이 필딩은 HTTP에 대해 전혀 언급하지 않았으며 순수하게 REST 시스템을 구성하는 방법에 대해서만 소개 하였습니다.

이번 포스팅의 목적은 웹과 무관한 REST 시스템을 본질을 이해하고, HTTP 프로토콜을 이용한여 REST 시스템을 설계하는 방법에 대해 이해하는 것 입니다.

REST

REST는 간단하게 말하자면, 존재하는 자원의 식별하고 제어하는 방법론 입니다.

REST 에서 정의 하는 자원에 대한 정의를 알아보고 자원의 제어 자원의 표현은 무엇인지 알아봅시다.

자원 (Resource)

자원이란 일이 처리되는 비용을 의미합니다.

REST 는 소프트웨어 아키텍쳐 이므로 컴퓨터의 자원을 의미합니다.

컴퓨터의 자원은 CPU가 수행하는 명령, 하드디스크에 저장되는 파일들, 메모리에 저장되는 데이터들을 의미합니다.

REST컴퓨터 자원을 사용하여 처리하는 한 단위의 작업을 식별할 수 있어야 합니다.

REST자원을 식별 할 수 있는 식별자가 필요합니다. 예를든다면 TIMESTAMP 나 UUID 같은 중복되지 않는 정보들을 식별자로 사용할 수 있습니다.

자원의 제어 (Resource Methods)

자원의 제어 는 흔히 CRUD 라 부르는 생성, 읽기, 변경, 삭제 행위를 자원에 수행하는것을 의미합니다.

이때 제어 방법은 일관적인 인터페이스로 구성되어야 합니다. 이는 소프트웨어의 API 처리 법칙을 정하면 일관적이게 규칙을 따라야 한다는 것입니다. 예를들어 웹 기반(HTTP)의 시스템에서 자원의 변경을 POST 메소드로 한다면(PUT이 더 어울릴지라도) 자원의 변경은 POST 메소드로 일관적이게 처리해야 한다는 점입니다.

자원의 표현 (Resource Representation)

자원의 표현은 조회한 순간의 자원 상태를 의미합니다. REST 시스템의 자원의 표현자기 서술적인(self-descriptive) 메시지와 HATEOAS(hypermedia as the engine of application state)로 구성됩니다. 이는 데이터를 설명하는 메타 데이터, 다음 자원으로의 이동을 안내하는 하이퍼 텍스트 등이 포함 되는 데이터를 의미합니다. REST 시스템은 클라이언트가 자원의 표현만 보더라도 이해되는 것을 목표로 합니다.


웹 기반(HTTP)의 REST

많은 자료들이 설명하고 있는 REST 시스템은 HTTP 기반으로 구성된 REST 시스템 입니다.

HTTP 기술을 통해 REST 시스템을 어떻게 구현하는지 알아봅시다.

자원의 식별

HTTPREST 시스템이 요구하는 자원의 식별URI의 정의로 처리합니다.

자원은 명사로 커뮤니케이션을 하기 때문에 많은 웹 기반 REST 시스템 선구자들은 URI을 명사구로 표현함으로써 자원을 나타내려고 노력했습니다.

다음과 같은 URI 표기법을 따릅니다.

  • URI의 세그먼트는 동사가 아닌 명사 사용.
    • users/mommoo/name (O)
    • users/mommoo/getName (X)
  • 만약 컨트롤 자원이라면 예외적으로 동사구 허용.
    • users/mommoo/name/duplicate (중복 이름 검사 API)
  • 자원의 관계가 표시되도록 작성.
    • users/mommoo/devices/android-phone
    위 예시는 유저 목록중 Mommoo를 의미하고, Mommoo가 가지고 있는 디바이스들을 의미하며, 디바이스들중 안드로이드 폰을 의미합니다.

자원의 제어

HTTP자원의 제어HTTP Method로 표현합니다. 대표적으로 POST, GET, PUT, DELETE 4개의 Method를 사용 합니다.

자원을 URI로 식별하고 URI에 행위를 붙여줌으로써 자원을 제어합니다.

아래는 자원 제어의 예시입니다.

  • GET users/mommoo/name (이름을 조회합니다.)
  • POST users/mommoo/name (이름을 등록합니다.)
  • PUT users/mommoo/name (이름을 수정합니다.)
  • DELETE users/mommoo/name (이름을 삭제합니다.)

자원의 표현

HTTP는 자원의 표현을 HTTP 응답 메시지로 구현합니다.

REST 자원의 표현의 특징인 self-descriptiveHATEOS를 만족하기 위해 ContentType 또는 커스텀 HTTP 헤더에 메타데이터 명시, 데이터에 링크를 포함하는 등의 기법을 사용합니다.

응답 예시는 https://slides.com/eungjun/rest#/79/0/1 참고해주세요.


REST-FUL

REST 시스템의 구성 요소는 다음과 같이 6개로 구성됩니다.

  • Client-Server
  • Stateless
  • Cacheable
  • Unitform-Interface
  • Layered-System
  • Code on demand (optional)

위 6가지 항목을 만족하는 HTTP REST 시스템을 구현한다고 가정할때, Unitform-Interface 항목을 제외한 나머지 항목들은 자연스럽게 구현이 되거나 조금만 신경을 쓴다면 어렵지 않게 구현할 수 있습니다.

Unitform-Interface 항목은 제외가 됬을까요? Unitform-Interface를 제공하기 위해 수행해야할 특징 중 self-descriptiveHATEOSHTTP 시스템에서 자연스럽게 처리 되지 않기 때문입니다.

사실 self-descriptiveHATEOS 속성은 데이터가 독립적으로 자생하기 위해 필요한 요소들이라 볼 수 있습니다. 그렇다보니 HTTP 서버 스펙을 구현할 때 데이터 독립적인 요소들까지 챙기지 않는 경우도 많습니다. 하지만 REST의 철학을 따르므로 REST 시스템이라 부르고 있습니다.

REST의 구성요소를 완벽하게 지키지 않은 REST 시스템을 구분하기 위해서인지 REST의 구성요소 (특히 Unitform-Interface)를 완벽하게 지킨 REST 시스템을 REST-FUL 시스템이라 부르고 있습니다.

로이 필딩은 REST 시스템의 규칙을 하나라도 제공하지 않는다면 REST 시스템이 아니라고 주장합니다.

정리하자면 REST 시스템으로 소개 되고 있는 시스템은 Unitfor-Interfaceself-descriptiveHATEOS가 지켜지지 않는 경우도 많으며, 나머지 항목까지도 완벽히 구현한 시스템을 REST-FUL 하다고 표현 합니다.


REST-API

API는 컴퓨터의 자원 제어 방법의 집합입니다.

그렇다면 REST-APIREST 시스템의 자원 제어 방법의 집합으로 정의할 수 있습니다.

한단계 더나아가 REST-FUL APIREST의 구성요소를 완벽히 따른 시스템의 자원 제어 방법의 집합이라 정의 할 수 있겠습니다.


오늘 포스팅은 여기까지 입니다.

읽어주셔서 감사합니다.

참고문헌

https://restfulapi.net/

그런 REST-API로 괜찮은가?

'네트워크' 카테고리의 다른 글

[네트워크] OSI 7계층  (0) 2021.07.26
[네트워크] HTTPS 프로토콜  (1) 2021.07.16

포스팅이 도움 되셨다면, 커피 한잔 후원해주세요!
더 좋은 포스팅 작성에 큰 힘이 됩니다.

Buy me a coffeeBuy me a coffee

안녕하세요.

오늘은 OSI 7계층에 대해 간략하게 소개합니다.

OSI 7 Layer

OSI 7계층 이란 네트워크 통신을 수행할 때, 처리되어야 할 작업을 순차적으로 7단계로 처리 하는 과정을 의미합니다.

계층을 나누어 처리함으로써, 필요한 작업들은 독립적인 모듈로 처리 됩니다. 이는 디버깅이 용이하고 모듈간 교체 및 확장등이 자유롭다는 장점이 존재합니다.

OSI 1~3 계층하드웨어 영역으로써, 각 층마다 매칭되는 하드웨어 장치가 존재합니다. 따라서, 해당 계층의 역할들은 하드웨어가 실질적으로 수행하는 역할 입니다.

OSI 4~7 계층소프트웨어 영역이며, 4~6 계층OS7계층은 우리가 사용하는 프로그램이 해당 계층의 역할을 수행합니다.

다음 이미지는 OSI 7계층 구성도 입니다.


Physical Layer

네트워크 통신은 서로 멀리 떨어져 있는 지점끼리 데이터를 주고 받을 수 있습니다. 데이터 통신은 아날로그 신호(주파수)로 최초 전달 되고 디지털 데이터로 변환되어 해석하는것을 의미합니다.

물리 계층(Physical Layer)은 이러한 아날로그 신호(주파수)를 디지털 신호로 변경해주는 역할을 수행합니다.

물리 계층의 역할은 여러 하드웨어의 조합으로 수행됩니다. 아날로그 신호를 디지털 테이터로 변환하는 주된 역할은 NIC(Network Interface Controller)란 하드웨어가 수행합니다. 흔히 네트워크 카드, 랜 카드로 불립니다.

Data-Link Layer

네트워크 통신은 여러 프로그램이 동시적, 지속적으로 수행 할 수 있습니다. 이때, 컴퓨터는 들어온 데이터를 식별하기 위한 라벨링 작업이 필요합니다. 이러한 행위를 프레임화 라고 부릅니다.

데이터 링크 계층(Data-Link Layer)프레임화를 진행하고, 만들어진 프레임을 상위 계층 또는 하위 계층에 전달 합니다.

결론적으로, 해당 계층은 두가지 역할로 정리할 수 있습니다.

  • 프레임화 (데이터 라벨링)
  • 흐름제어 (상위 계층 또는 하위 계층으로 프레임 전달)
    3계층, 1계층도 하드웨어 영역이므로 인접한 네트워크 장비에 데이터를 전송하는것을 의미합니다.

해당 계층의 역할을 수행하는 대표적인 하드웨어는 위에서 언급한 NIC 입니다. 해당 계층의 역할을 전문적으로 수행하는 브릿지, 스위치 같은 장비들도 존재합니다.

Network Layer

물리 계층의 아날로그 신호는 거리가 먼 지점까지 전달되지 않습니다.

신호를 세게 하는 리피터라는 장비를 사용 할 수 있지만, 이는 특정 지점에 전달 하기 보다 무분별하게 전파하기 때문에 효율이 떨어 집니다.

이를 해결하기 위해 사용되는 장비는 바로 라우터 입니다. 무분별하게 전파하는 리피터와는 다르게 라우터는 내장된 라우팅 알고리즘을 통해 전달 할 수 있는 가장 가까운 라우터 까지의 경로를 결정하고 이를 테이블로 저장합니다. 해당 행위를 라우팅 이라 표현 합니다.

경로가 결정되면 전달해야할 데이터를 다음 라우터에게 맡깁니다. N개의 라우터가 지속적으로 정보를 전달을 하면서 최종 목적지 까지 전달하는 방법을 포워딩 이라 표현 합니다.

이때, 정보를 전달 받은 라우터는 본인이 최종 목적지 인지 여부와 응답 데이터를 다시 출발지 라우터로 보내기 위한 데이터가 필요합니다. 즉 전달해야 하는 데이터는 출발지 정보, 목적지 정보가 부가적으로 필요 하며 해당 정보는 IP 라는 정보로 처리합니다. 전달 데이터에 IP 정보를 붙인 데이터를 패킷 이라 부릅니다.

정리하자면 해당 계층은 3가지 역할을 수행합니다.

  • 2계층에서 넘어온 데이터를 패킷으로 만들거나, 수신된 패킷 데이터를 해석합니다.
  • 다음 라우터의 경로를 찾기 위한 라우팅을 진행합니다.
  • 패킷 전달의 역할을 다음 라우터에게 위임하는 포워딩을 진행합니다.

해당 계층에 대표적인 하드웨어는 위에서 언급했던 라우터 이며 우리가 집에서 흔히 사용하는 공유기라우터의 역할을 어느정도 수행 합니다.

Transport Layer

데이터 통신은 여러 프로그램이 동시에 지속적으로 수행되고 있습니다.

그렇기에 특정 데이터가 어떤 프로그램과 관련이 있는지 식별할 수 있어야 합니다.

식별하기 위해 포트번호 라는 데이터가 사용됩니다.

전송 계층(Transport Layer)은 하위 계층에 데이터를 전달 할때 데이터에 포트번호를 붙이며, 하위 계층으로 부터 데이터를 전달 받을 때도 포트번호 를 통해 데이터를 식별합니다.

또한 데이터 통신 프로토콜에 따른 알고리즘이 수행됩니다. 대표적인 예로 TCP, UDP 프로토콜이 존재합니다.

TCP 통신이 제공하는 연결지향, 흐름제어, 오류검출 및 회복 등이 해당 계층에서 수행됩니다.

해당 계층의 역할은 운영체제 커널에 소프트웨어적으로 구현되어 있습니다.

정리하자면 해당 계층은 크게 2가지 역할을 수행합니다.

  • 포트번호를 통한 데이터 식별 작업.
  • 데이터 통신 프로토콜에 따른 알고리즘 수행.

Session Layer

Warning! 해당 계층은 작성자가 정확히 이해하지 못했습니다.

세션 계층(Session Layer)의 주된 목표는 각 프로그램의 네트워크 통신 상태 관리동기화 입니다.

상태 관리는 데이터 통신 프로토콜 알고리즘이 가지는 특성들을 수행하기 위해 필요한 처리를 의미합니다. 예를들어 TCP 프로토콜은 연결 수립, 종료와 같은 상태 등을 처리합니다.

동기화전송 계층에서 올라온 또는 응용 계층 에서 내려온 데이터를 안정적으로 상위 또는 하위 계층으로 전달하는 역할을 수행합니다. 데이터가 성공적으로 전달된 지점까지 내부적으로 마킹해두며, 데이터 전달에 문제가 발생하면 마킹한 지점부터 오류지점까지 데이터 복구 절차가 수행됩니다.

해당 계층 역할도 운영체제가 수행합니다.

Presentation Layer

표현 계층(Presentation Layer)은 하위 계층이 전달한 데이터를 어플리케이션이 해석 할 수 있도록 데이터를 디코딩 하거나, 데이터 전달을 효율적으로 수행하기 위해 데이터를 인코딩 한 뒤 하위 계층으로 전달합니다.

다음은 표현 계층이 수행하는 대표적인 예시 입니다.

  • SSL 프로토콜에서 처리되는 암, 복호화 처리
  • 데이터 압축해제 처리
  • 데이터 포맷(UTF-8 과 같은)에 따른 인코딩, 디코딩 처리

해당 계층 역할 역시 운영체제가 수행합니다.

Application Layer

응용 계층(Application Layer)은 요구사항을 처리하기 위해 네트워크 통신을 이용한 데이터의 송-수신이 발생하는 가장 마지막 영역 입니다.

운영체제는 전송 계층에서 제공하는 API를 활용하여 네트워크 통신을 가능토록 API를 제공하는데, 이를 소켓 API라 부릅니다.

해당 계층은 소켓 프로그래밍을 통해 데이터를 송신 및 수신을 수행합니다.

재밌는 특징은 각 프로그램이 개별적으로 데이터 규격을 만들어 통신 할 수 있습니다. 데이터의 인코딩 및 디코딩을 각 프로그램이 자체적으로 수행할 수 있기 때문입니다.

프로그램이 대표적으로 사용하는 데이터 규격은 HTTP 프로토콜 방식이 있으며 작은 단위로는 JSON, XML과 같은 데이터 규격도 존재합니다.

해당 계층의 역할은 개발된 프로그램이 수행합니다.

TCP/IP 모델의 등장

독립적인 모듈을 구성하는것은 정답이 존재하지 않습니다. 나뉘어진 모듈이 서로 심하게 의존하는 경우 모듈의 결합도가 높다고 하며, 모듈이 너무 작은 단위로 구성 된 경우 응집도가 떨어진다고 합니다. 이러한 특징들은 소프트웨어적 가치를 하락시키는 요인입니다.

OSI 7계층은 대표적인 네트워크 통신 규격으로 사용 되고 있지만, OSI 7계층역시 결합도가 높고, 응집도가 낮은 모듈들이 존재합니다.

그 대상 계층들은 응용 계층, 표현 계층, 세션 계층 입니다. 따라서 현대적인 네트워크 통신 규격인 TCP/IP 모델 은 다음과 같이 정의 되었습니다.

TCP/IP 모델네트워크 엑세스 계층데이터 링크 계층 + 물리 계층 으로 나누어서 표현하기도 합니다.

반면에 응용 계층, 표현 계층, 세션 계층 들은 응용 계층 하나로 통합 되었습니다.


TCP/IP 모델의 각 계층 역할도 OSI 7계층의 역할과 동일합니다.

몇몇 모듈이 독립적으로 수행되던 역할이 하나의 모듈이 통합 수행 한다고 이해하면 될거 같습니다.

오늘 포스팅은 여기까지 입니다.

읽어주셔서 감사합니다.

'네트워크' 카테고리의 다른 글

[네트워크] REST API  (0) 2021.08.08
[네트워크] HTTPS 프로토콜  (1) 2021.07.16

포스팅이 도움 되셨다면, 커피 한잔 후원해주세요!
더 좋은 포스팅 작성에 큰 힘이 됩니다.

Buy me a coffeeBuy me a coffee

안녕하세요.

오늘은 HTTPS 통신 에 대해 포스팅 합니다.

HTTPS 통신 은 데이터를 암호화 하여 통신하도록 설계되어 보안적인 요소가 강화된 HTTP 통신 입니다.

HTTPS 통신HTTP 통신 과 다르게 서버가 제공하는 SSL 인증서 라는 요소가 추가되었으며, 이를 통해 클라이언트는 필요한 서버의 정보를 취득하고 신뢰성을 판단합니다.

데이터 암호화

HTTPS 통신 방법에 앞서, 간단하게 데이터 암호화 개념을 살펴보면 좋습니다.

암호화 란 평문을 암호문으로 변경하는것을 의미합니다.

반대로 복호화 는 암호문을 평문으로 변경하는것을 의미합니다.

평문: 사람이 이해할 수 있는 데이터

암호화는 어떤 특정 데이터를 사용하여 수행하는데, 이 특정 데이터를 암호키 라고 부릅니다.

암호화는 크게 두가지 방식이 있습니다.

  • 대칭키 방식
  • 공개키 방식

대칭키 방식

대칭키 방식은 말그대로 암호키 가 대칭임을 의미 합니다.

암호화 할때도, 복호화 할때도 똑같은 1개의 암호키 를 사용하는 것이 특징입니다.

통신 하려는 대상 서로가 암호키 를 알고 있으면 매우 유용합니다.

하지만 불특정 다수와 통신을 하기 위한 안전한 암호키 전달이 무척 어렵습니다.

해커가 중간에 암호키 를 취득 해버리면 데이터를 암호화 하는게 의미가 없기 때문입니다.

Q. 암호키암호화 해서주면 안되나요? A. 암호화 를 하기위해서는 무조건 최초로 평문으로된 암호키 를 넘겨주어야만 합니다. 암호키암호화 해버리면 클라이언트는 복호화 를 할 수 있는 키를 모르기 때문입니다.

공개키 방식

공개키 방식은 암호키 가 두가지 존재합니다.

  • 공개키
  • 비공개키(개인키, 비밀키)

대칭키 방식 과는 다르게 암호화 할때 공개키를 사용했으면 복호화비밀키 를 사용해야 합니다.

반대로, 암호화 할때 비밀키 를 사용했다면 복호화공개키 로만 가능합니다.

공개키 방식의 장점

공개키 방식대칭키 방식 의 키를 안전하게 전달하기 어려운 단점을 어느정도 해소 하였습니다.

서버가 개인키 를 소유하고 있고, 불특정 다수에게 공개키 를 전달합니다.

이때, 해커가 공개키 를 획득 할 수 있고 그로인해 서버가 내려주는 데이터 를 해석은 할 수 있지만 클라이언트에게 공격하지는 못합니다.

예를들어, 서버가 클라이언트에게 A의 장소 를 알려줬습니다. 이때 해커는 공개키 를 취득해 복호화 하여 내용을 읽었고 클라이언트에게 B의 장소 로 속이고 싶습니다.

해커가 데이터를 변경하더라도 서버가 가지고 있는 비밀키 를 알아야 클라이언트가 속을 수 있는 암호문 을 만들 수 있습니다.

해커가 임의로 암호문을 만들어버리면 클라이언트는 공개키 로 복호화에 실패할것이고, 결국 클라이언트에게 공격하지 못하는 상황이 발생합니다.

물론 클라이언트가 서버의 서비스를 이용 못하는건 있습니다. 하지만 공격 받지 않는것이 핵심입니다.

반대로 클라이언트가 서버로 데이터를 보낼 때는 공개키 로 데이터를 암호화 하여 보냅니다.

해커는 공개키 만알고 있기 때문에 클라이언트 데이터를 읽지 못합니다. 왜냐면 공개키 방식공개키암호화 를 하면 비밀키 로만 복호화 를 진행할 수 있기 때문입니다.

정리하자면 공개키 방식 은 클라이언트로 하여금 데이터가 변경되지 않음을 보장할 수 있고 안전하게 데이터를 서버로 보낼 수 있는 장점이 있습니다.

공개키 방식의 단점

하지만 공개키 방식도 한계가 존재합니다. 클라이언트 → 서버로 데이터를 암호화 해서 보내는건 문제가 되지 않습니다. 해커가 읽지도 못하니깐요.

하지만 서버 → 클라이언트로 보내는 데이터는 해커가 읽을 수 있습니다. 만약 데이터가 민감한 개인 정보같은게 포함되어 있다면 해커가 읽는것만으로도 피해가 생길 수 있기 때문입니다.

또한 공개키 방식대칭키 방식 보다 암-복호화 속도가 느립니다.

SSL 인증서

HTTPS 통신 에서는 서버가 SSL 인증서 를 제공한다고 언급했습니다.

SSL 인증서는 크게 두가지 역할을 수행합니다.

  • 서버 본인이 신뢰할 수 있는 서버임을 증명하는 수단.
  • 서버가 제공하는 공개키를 전달.

SSL 인증서 는 서버의 신뢰성을 판단할 수 있는 수단이라 했는데, 다짜고짜 클라이언트에게 SSL 인증서 를 내밀면 신뢰할 수 있을까요?

예를들어, 모르는 사람이 다가와서 나 믿을 수 있는 사람이야 라고 말하면 여러분을 믿을 수 있으신가요?

그렇기에 SSL 인증서 의 신뢰성을 대신 보장하는 제 3자가 존재합니다.

그 3자를 CA(Certificate authority) 혹은 Root Certificate 라 일컫는 기업들입니다.

해당 기업들은 세계적인 기업으로써, 신뢰성이 엄격하게 공인된 기업들만 CA로써, 참여할 수 있습니다.

이러한 기업은 SSL 인증서 를 신청한 기업들이 신뢰성있는 기업인지 평가한 후 발급을 진행합니다.

CA 기업들은 잘 알려진 기업들로써, HTTPS 통신을 지원하는 클라이언트(대표적으로 브라우저)들은 CA 리스트 를 보유하고 있습니다. 그렇기에, 클라이언트는 SSL 인증서 를 받은 후 정보를 읽어 CA 리스트 대조를 통해, CA 가 발급한 SSL 인증서 의 유무를 판단하고 신뢰성을 평가합니다.

CA 가 발급하지 않은 SSL 인증서 는 클라이언트가 신뢰성을 낮게 평가합니다.

SSL 인증서 암호화

SSL 인증서는 비공개키 방식 으로 암호화하여 클라이언트에게 전달됩니다.

이때, 암호화 를 수행하는 대상은 서버가 아닌, CA 에서 자체적으로 소요한 비밀키 를 통해 암호화 를 진행합니다.

SSL 인증서 를 서버에서도 변조하여 클라이언트에게 공격할 수 없습니다. 비밀키 를 모르기 때문입니다.

CA공개키는 이미 널리 알려진 정보로써, 클라이언트가 CA 리스트 와 함께 공개키 도 보유하고 있습니다. 그렇기에 위에 앞서 언급한 공개키 방식 장점을 잘 활용하고 있다고 볼 수 있습니다. SSL 인증서 가 위조되지 않음을 보장받을 수 있기 때문입니다.

SSL 인증서에 포함된 공개키

SSL 인증서엔 공개키가 포함되어 있는데 이는, CA공개키가 아닙니다. 서버가 클라이언트와 보안 통신을 하기위해 서버가 직접 생성한 공개키 입니다.

서버가 CA 에게 SSL 인증서 의 발급 신청을 할 때, 몇몇 서버 데이터를 전달하는데 필수적으로 공개키 도 전달이 되어야 합니다.

뒤에 설명할 SSL 통신 에서는 클라이언트가 SSL 인증서 를 통해 서버의 공개키 를 취득하고, 비공개 방식 으로 보안 통신하는 절차가 있기 때문에 필수적으로 필요합니다.

SSL 통신

공개키 방식 으로 통신을 하면, 서버 → 클라이언트로 데이터를 내려줄땐 조금 문제가 될 순 있지만, 어느정도 감안하고 보안 통신 방법으로 사용할 수 있을거 같습니다.

하지만, 큰 단점이 있는데요.

그것은 바로 공개키 방식은 암호화 복호화 하는 과정이 느리다 라는 것 입니다.

웹통신이 느리면, 문제가 될 수 있기 때문에 SSL 통신 은 상대적으로 빠른 대칭키 방식 으로 메인 통신을 진행합니다.

하지만, 대칭키는 공격자가 알면 너무나도 쉽게 데이터를 변조하여 대상을 속일 수 있기 때문에 매우 위험합니다. SSL 통신은 어떻게 이런 이슈들을 해결했을까요?

SSL 통신 방법

결론적으로 말하자면, SSL 통신은 공개키 방식대칭키 방식 둘 다 사용합니다.

SSL 통신은 다음의 아이디어를 사용합니다.

공개키 방식 으로 서버와 함께 작성된 대칭키 를 서로에게 전달합니다. 이때 중간 공격자는 서버의 개인키 를 알고있지 않는한 내용을 복호화하지 못하여 데이터 해독이 불가능 합니다.

이렇게 서로 안전하게 대칭키 가 전달되었다면, 암-복호화가 빠른 대칭키 로 데이터 통신을 합니다.

SSL 통신 절차

TCP와 같은 연결지향 프로토콜은 크게 아래의 과정을 거칩니다.

  • 악수(HandShake)
  • 데이터 전송(세션)
  • 세션 종료

SSL 통신도 결국 TCP위에서 동작하므로, 위 과정과 같습니다만, 세부적인 내용이 조금 다릅니다.

SSL 통신은 TCP의 핸드쉐이크 (SYNSYN ACKACK) 과정이 이루어 진 후에, SSL 통신이 시작됩니다. (악수 → 데이터 전송 → 세션 종료)

악수(HandShake)

  1. Client Hello (클라이언트가 서버에 접속합니다. )
    • 서버에게 평문 문자열 Client Hello 를 전송합니다.
    • 서버에게 대칭키 를 만들 수 있는 랜덤 데이터를 평문으로 전송 합니다.
  1. Server Hello (서버가 Client Hello 를 받은 후, 클라이언트에게 응답합니다.)
    • 클라이언트에게 평문 Server Hello 를 전송합니다.
    • 클라이언트에게 대칭키 를 만들 수 있는 랜덤 데이터를 평문으로 전송합니다.
    • 제일 중요한 SSL 인증서 를 전송합니다.
  1. 클라이언트의 SSL 인증서 신뢰성 판단
    • 서버에게 받은 SSL 인증서 를 보유하고 있는 CA 리스트를 통해 복호화 합니다.
    • 복호화 에 성공하였다면, 해당 서버를 신뢰할 수 있다고 판단합니다.
  1. 서버에 대칭키 전송 (SSL 핸드쉐이크의 핵심 목적 입니다.)
    • 클라이언트는 본인이 만든 랜덤 데이터와 서버에서 받은 랜덤 데이터를 이용하여, 대칭키 를 구성합니다.
    • 해당 대칭키를 SSL 인증서 에 포함되어 있는 서버 공개키암호화 하여 서버에게 전송합니다.
  1. 핸드쉐이크 종료
    • 클라이언트와 서버가 서로 대칭키 를 안전하게 전달 받은 후, 통신 준비가 되었다는 신호와 함께 핸드쉐이크가 종료됩니다.

데이터 전송(세션)

서버와 클라이언트가 데이터를 서로 주고 받고 하는 단계입니다. 서로 안전하게 전달받은 대칭키 를 사용하여, 암-복호화를 빠르게 진행합니다.

세션종료

데이터 전송이 끝나면 SSL 통신이 끝났음을 서로에게 알려줍니다.

오늘 준비한 포스팅은 여기까지 입니다. 읽어주셔서 감사합니다.

'네트워크' 카테고리의 다른 글

[네트워크] REST API  (0) 2021.08.08
[네트워크] OSI 7계층  (0) 2021.07.26

포스팅이 도움 되셨다면, 커피 한잔 후원해주세요!
더 좋은 포스팅 작성에 큰 힘이 됩니다.

Buy me a coffeeBuy me a coffee

+ Recent posts