서버 개념 키워드 (2) #프로토콜 #SSH #HTTP와 HTTPS차이
프로토콜
클라이언트 - 서버 간 통신 약속
프로토콜의 종류
HTTP ( Hyper Text Transfer Protocol )
웹 상에서 데이터를 주고받을 수 있는 프로토콜, 80번 포트 사용
구조
- 요청/상태라인
- General Header- 클라이언트, 서버 또는 HTTP와 관계된 정보
- Request Header- 요청 형식과 서버의 매개 변수
- Response Header- 응답을 보내는 서버에 대한 정보
- Entity header- 메시지 바디의 컨텐츠를 나타내는 HTTP 헤더
- CRLF- 공백 (공백을 뭐 어려운 말로 적어놨다.)
- Body- 내용
동작 방식
클라이언트가 브라우저를 통해서 어떤 서비스를 url이나 다른 수단으로 서버에 요청하면, 서버에서 해당 요청사항에 맞는 결과를 응답한다.
ex) 웹 브라우저로 네이버에 접속하여 데이터를 전송하고 네이버 서버에서 응답받는 것
특징
- HTTP 메시지는 HTTP 서버와 클라이언트에 의해 해석된다.
- TCP/IP 를 이용하는 응용 프로토콜이다. (다음장에서 설명)
- 연결상태를 유지하지 않는 비연결성 프로토콜이다. (요청 / 응답 방식이 그 예이다)
장점
- 불특정 다수를 대상으로 하는 서비스에는 적합하다.
- 클라이언트와 서버가 계속 연결된 형태가 아니기 때문에 클라이언트와 서버 간의 최대 연결 수보다 훨씬 많은 요청과 응답을 처리할 수 있다.
단점
- 연결을 끊어버리기 때문에, 클라이언트의 이전 상황을 알 수가 없다. 이러한 특징을 무상태(Stateless)라고 말한다.
- 이러한 특징 때문에 정보를 유지하기 위해서 Cookie와 같은 기술이 등장하게 되었다.
HTTPS ( Hyper Text Transfer Protocol )
Secure가 추가 된 것! 즉 내가 웹사이트에 보내는 정보를 다른 사람이 중간에 확인할 수 없게 통신 내용을 암호화 하는 프로토콜, 443번 포트 사용
ex) 로그인 과정에서 그냥 HTTP로 정보를 전달하면 아이디와 비밀번호가 그대로 노출됩니다.
간혹 신뢰할 수 없는 사이트라고 네이버 whale이나 크롬에서 나타나는 경우를 많이 볼 수 있는데 그러한 경우는 기관으로 부터 검증되지 않은 방식을 사용하는 것이라고 생각하면 됩니다.
HTTPS의 장단점
장점
- 해커가 웹사이트와 사용자 사이의 통신을 몰래 수신하는 것을 방지한다.
- 사용자의 명시적인 권한 허락(사진 촬영 기능 등)을 업데이트때 마다 권한 허락을 가능하게 한다.
- 접속한 사이트가 정말 내가 접속한 사이트가 맞는지 확인할 수 있다.(피싱 사이트가 아닌지)
- 구글, 네이버 등 SEO(Search Engine Optimization) 관련 내용을 HTTPS 웹사이트에 적용한다. (EX : 키워드 상위 노출)
단점
- 모든 사이트에서 텍스트를 암호화해서 주고받으면 과부하로 속도가 저하된다다. 그래서 필요에 따라 사용해야 한다.
- HTTPS가 무조건 안전한 것은 아니다. 신뢰할 수 있는 CA가 아닌 자체 인증서를 발급할 수도 있기 때문이다.
SMTP (Simple Mail Transfer Protocol)
인터넷에서 메일을 주고받기 위해 이용하는 프로토콜, 25번 포트 사용
예시
내가 네이버 메일 서버에 데이터를 전송하는 것
네이버 메일 서버에서 구글 메일 서버로 데이터를 전송하는 것
하지만 구글 메일 서버 보관함에서 데이터를 내려받는 것은 SMTP가 아니다.
FTP (File Transfer Protocol)
인터넷에서 파일을 주고받기 위해 이용하는 프로토콜, 21번 포트를 사용한다.
SFTP (Secure File Transfer Protocol)
SSH가 추가되어 보안 등급이 높은 파일을 주고 받는 데 사용하는 프로토콜, 22번 포트를 사용한다.
(SSH는 뒤에서 추가 설명)
TELENT (Telecommunication Network Protocol)
인터넷을 통해 원격 호스트 컴퓨터에 접속할 경우 지원되는 인터넷 프로토콜, 23번 포트를 지원한다.
SSH (Secure Shell Protocol)
다른 컴퓨터와 보안적으로 안전하게 통신하기 위해 사용하는 프로토콜
암호화 방식
공개키 방식으로 대칭키를 전달하고, 그 대칭키로 통신한다.
대칭키 방식이란?
메세지를 보내는쪽이 암호화를 하고 메세지를 받는 쪽이 다시 복호화는 방식을 공유한다.
특징
- 동일한 키로 암호화, 복호화가 가능하다.
- 랜덤으로 생성되어 유출되어도 다음 사용 시 다른 키가 사용되어 안전하다.
- 공개키보다 빠르게 통신할 수 있다.
한계
이 키를 공유하는 방식은 결국 처음 한번은 키를 전송을 해야한다. 이 과정에서 해커에게 노출될 수 있다.
공개키(비대칭키) 방식이란?
- A키로 암호화를 하면 B키로만 복호화를 할 수 있다. 그 역도 가능하다.
- 둘중 하나를 비공개 키(Private Key)로 부르며 이는 자신만 가지고 공개되지 않는다.
- 나머지 하나는 공개 키(Public Key)로 부르며 타인에게 제공되고 유출이 되어도 비공개 키를 모르면 복호화(암호 풀기)할 수 없어 안전하다.
- 하지만 전송되는 정보가 '피싱이 아닌 상대방'임을 증명할 수 있는 방법 : 전송되는 정보 중 일부는 상대방의 개인 키로 암호화 된 정보로 전송이 된다. 만약 피싱 사이트에서 정보를 보낸다면 공개 키로 풀리지 않기 때문에 걱정이 없다. 다만, 공개키는 신뢰할 수 있는 기관에서 검증이 되어야 한다!
동작
- 서버(사이트)는 공개키와 개인키를 만들고, CA(인증기관)에 자신의 정보와 공개키를 관리해달라고 계약하고 필요시 돈을 지불한다.
- 이 때 CA는 기관만의 공개키와 개인키가 있다.(서버의 공개키와 개인키와 별개) CA는 서버가 제출한 데이터를 검증하고, CA의 개인키로 서버에서 제출한 정보를 암호화해 인증서를 만들어 제공한다.
- CA는 웹 브라우저에게 자신의 공개키를 제공한다.
- 초기 상태에는 클라이언트는 서버를 신뢰 할 수 없다. 그래서 이를 확인하는 탐색 과정(HANDSHAKE)이 필요하다.
- 먼저 클라이언트가 무작위의 데이터를 서버에 전송한다. 그러면 서버는 답변으로 무작위 데이터와 해당 서버의 인증서를 같이 싣어 보낸다.
- 그러면 클라이언트는 이 정보가 진짜인지 브라우저에 내장된 CA의 정보를 통해 확인한다.(비대칭키를 사용)
- CA의 인증을 받은 인증서는 해당 CA의 개인키로 암호화가 되어있다. 그렇기 때문에 브라우저에 저장된 CA의 공개 키로 복호화할 수 있다. (만약 CA 리스트에서 이 인증서가 해당하는 것이 없다면 신뢰할 수 없다는 경고가 뜬다.)
- 복호화된 인증서에는 서버의 공개키가 포함되어 있다.
- 이후에는 대칭키 방식을 사용한다. (비대칭키 방식을 사용하지 않는 이유는 다량의 데이터를 암호화 복호화 하는 것이 무리이기 때문)
- 대칭키를 어떻게 주고받았는가(비대칭키 방식을 사용) : 무작위 데이터를 준것과 받은 것을 혼합하여 임시 키를 만든다. 그리고 그 키를 서버의 공개키로 암호화해서 서버로 보낸 다음 일련의 과정을 거쳐 동일한 대칭 키를 갖게 된다.