HTTP/HTTPS

📌 HTTP

 

HTTP

• 클라이언트 서버 구조
  • Request Response 구조
• 무상태 프로토콜(Stateless)
  • 로그인이 필요 없는 단순한 서비스 소개 화면 같은 경우,,
  • 장점: 서버 확장성 높음(스케일 아웃)→(응답 서버를 쉽게 바꿀 수 있어 무한한 서버 증설 가능)
  • 단점: 클라이언트가 추가 데이터 전송
• 비연결성(Connectionless)
  • 요청을 주고받을 때만 연결을 유지하고 응답을 주고 나면 TCP/IP 연결을 끊는다
  • 따라서 최소한 자원으로 서버유지 가능
• HTTP 메세지
• 단순함, 확장 가능

 

 

 

📌 HTTPS (HTTP Secure)

암호화 방식

데이터를 암호화를 할 때에는 암호화할 때 사용할 키, 암호화한 것을 해석(복호화)할 때 사용할 키가 필요합니다.

이 때 암호화와 복호화할 때 사용하는 키가 동일하다면 대칭 키 암호화 방식,

다르다면 공개 키(비대칭 키) 암호화 방식이라고 합니다.

 

 

1. 대칭 키 암호화 방식

대칭 키 암호화 방식은 하나의 키만 사용합니다. 암호화할 때 사용한 키로만 복호화가 가능합니다.

두 개의 키를 사용해야하는 공개 키 방식에 비해서 연산 속도가 빠르다는 장점이 있습니다.

하지만 키를 주고 받는 과정에서 탈취 당했을 경우에는 암호화가 소용없어지기 때문에 키를 관리하는데 신경을 많이 써야 합니다.

 

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

비대칭 키 암호화 방식은 두 개의 키를 사용합니다. 암호화할 때 사용한 키와 다른 키로만 복호화가 가능합니다.

여기서 두 개의 키를 각각 공개 키, 비밀 키 라고 부릅니다.

 

여기서 공개 키는 이름 그대로 공개되어 있기 때문에 누구든지 접근 가능합니다.

누구든 이 공개 키를 사용해서 암호화한 데이터를 보내면, 비밀 키를 가진 사람만 그 내용을 복호화할 수 있습니다.

보통 요청을 보내는 사용자가 공개 키를, 요청을 받는 서버가 비밀 키를 가집니다. 이 때, 비밀 키는 서버가 해킹당하는 게 아닌 이상 탈취되지 않습니다.

 

이러한 공개 키 방식은 공개 키를 사용해 암호화한 데이터가 탈취 당한다고 하더라도, 비밀 키가 없다면 복호화할 수 없으므로 대칭 키 방식보다 보안성이 더 좋습니다.

하지만 대칭 키 방식 보다 더 복잡한 연산이 필요하여 더 많은 시간을 소모한다는 단점이 있습니다.

 

 

 

SSL/TLS 프로토콜

HTTPS는 HTTP 통신을 하는 소켓 부분에서 SSL 혹은 TLS라는 프로토콜을 사용하여 서버 인증과 데이터 암호화를 진행합니다.

여기서 SSL이 표준화되며 바뀐 이름이 TLS이므로 같은 사실상 같은 프로토콜이라고 생각하시면 됩니다.

SSL/TLS는 다음과 같은 특징을 가집니다.

• CA를 통한 인증서 사용
• 대칭 키, 공개 키 암호화 방식을 모두 사용

 

인증서와 CA(Certificate Authority)

HTTPS를 사용하면 브라우저가 서버의 응답과 함께 전달된 인증서를 확인할 수 있습니다.

 

이러한 인증서는 서버의 신원을 보증해줍니다.

이때 인증서를 발급해주는 공인된 기관들을 Certificate Authority, CA라고 부릅니다.

 

1. 서버는 인증서를 발급받기 위해서 CA로 서버의 정보와 공개 키를 전달합니다.

2. CA는 서버의 공개 키와 정보를 CA의 비밀 키로 암호화하여 인증서를 발급합니다.

3. 서버는 클라이언트에게 요청을 받으면 CA에게 발급받은 인증서를 보내줍니다.

4. 이 때, 사용자가 사용하는 브라우저는 CA들의 리스트와 공개 키를 내장하고 있습니다.

5. 우선 해당 인증서가 리스트에 있는 CA가 발급한 인증서인지 확인하고, 리스트에 있는 CA라면 해당하는 CA의 공개 키를 사용해서 인증  서의 복호화를 시도합니다.

6. CA의 비밀 키로 암호화된 데이터(인증서)는 CA의 공개 키로만 복호화가 가능하므로, 정말로 CA에서 발급한 인증서가 맞다면 복호화가 성공적으로 진행되어야 합니다.

 

• 복호화가 성공적으로 진행 된다면, 클라이언트는 서버의 정보와 공개 키를 얻게 됨과 동시에 해당 서버가 신뢰할 수 있는 서버임을 알 수 있게 됩니다.
• 복호화가 실패한다면, 이는 서버가 보내준 인증서가 신뢰할 수 없는 인증서임을 확인하게 됩니다.

 

정리하자면, 이렇게 서버와 클라이언트간의 CA를 통해 서버를 인증하는 과정과 데이터를 암호화하는 과정을 아우른 프로토콜을 SSL 또는 TLS이라고 말하고, HTTP에 SSL/TLS 프로토콜을 더한 것을 HTTPS라고 합니다.

 

 

---

 

HTTPS 사설 인증서 발급 및 서버 구현

Homebrew를 통해 설치(macOS)

brew install mkcert

인증서 생성

1. 로컬을 인증된 발급기관으로 추가

mkcert -install
//비번 -> 컴퓨터 비번

⇒

이렇게 뜬다!

1. 로컬환경에 대한 인증서 만들기 → 아래 명령어 입력

mkcert -key-file key.pem -cert-file cert.pem localhost 127.0.0.1 ::1

localhost, 127.0.0.1(IPv4), ::1(IPv6)에서 사용할 수 있는 인증서cert.pem, key.pem이라는 파일이 생성되었다.

⚠️ key.pem은 개인키라서. git에 커밋하지말고, 암호처럼 다루어야한다.

HTTPS 서버 작성

node.js 환경에서 https 내장 모듈을 이용해서 작성 가능하다.

express.js를 통해서 만들수도 있다.

방금 생성한 인증서 파일들을 HTTPS 서버에 적용해주는 작업이 선행되어야한다.

__dirname은 현재 실행 중인 파일 경로를 말하는 것으로, 절대경로를 넣어주면 된다.

로컬은 인증된 발급기관으로 등록이 되어있고, 인증서는 서버와 같은 경로에 있어야 한다.

 

 

Node.js https 모듈 이용

const https = require('https');
const fs = require('fs');

https
  .createServer(
    {
      key: fs.readFileSync(__dirname + '/key.pem', 'utf-8'),
      cert: fs.readFileSync(__dirname + '/cert.pem', 'utf-8'),
    },
    function (req, res) {
      res.write('Congrats! You made https server now :)');
      res.end();
    }
  )
  .listen(3001);

이제 서버를 실행한 후 https://localhost:3001로 접속하면 브라우저의 url 창 왼쪽에 자물쇠가 잠겨있는 HTTPS프로토콜을 이용한다는 것을 알 수 있다!

console.log(req.body);
  console.log(userInfo);

 

 

express.js 이용

const https = require('https');
const fs = require('fs');
const express = require('express');

const app = express();

https
  .createServer(
    {
      key: fs.readFileSync(__dirname + '/key.pem', 'utf-8'),
      cert: fs.readFileSync(__dirname + '/cert.pem', 'utf-8'),
    },
    app.use('/', (req, res) => {
      res.send('Congrats! You made https server now :)');
    })
  )
  .listen(3001);

만약 express.js 를 사용하는 경우,

다음과 같이 https.createServer의 두 번째 파라미터에 들어갈 callback 함수를 Express 미들웨어로 교체!

 

 

ngrok으로 터널링도 가능하다.

HTTP로 만들어진 서버를 HTTPS 프로토콜로 터널링 해주는 프로그램이라고 함!

ngrok - Online in One Line