저는 K-digital 교육을 받기 전에 9년동안 개발과 상관없는곳에서 일을했고 그 일을 하기전에

ITBank라는곳에서 해킹/보안 교육을 받았습니다.

그때 해킹기법에 네트워크 공부를 했었는데 너무 오래되서 기억이 가물가물한데

검색해가면서 정리해봤습니다.

원래는 같이 스터디하는 인원들과 같이 프로젝트를 진행하기전에 스터디를 위해 만든 자료인데 블로그에 올리게 되었습니다. 틀린 내용이 있다면 댓글에 적어주세요 🤣

개발공부를 하다보니 맨날 로컬환경에서 개발을 진행했었고 그러다보니 모든 프로젝트는 HTTP로 돌아갔습니다.
최근 프로젝트를 거의 완성하고 배포를 준비하다보니 HTTPS를 적용을 해야겠다는 생각이 들었습니다.
근데 왜?? 써야되는지 몰라서 직접 실험해보고 정리한글입니다.

이사트를 보면 URL입력하는데에 주의요함이라고 경고를 하고있습니다.

HTTP를 그냥 쓰면 어떤게 위험할까

와이어샤크를 이욯해서 위에 홈페이지 북사이트에 내가 보낸 패킷을 잡아 낼수있습니다.

HTTP로 통신을 할경우에 모든 패킷이 암호화를 안하고 보낸다는게 문제인데

해당 홈페이지의경우 HTTP를 이용하고 있어서 암호화가 안되지만 부분부분 뭔가 암호화해서 통신을 하고있

는거 같습니다.

일단은 다 GET요청으로만 요청을 보냈기때문에 더 확실하게 보기위해서 POST요청을 보내보겠습니다.

간단한 POST요청으로 회원가입을 해보기로 했습니다.

불안하기때문에 아이디만 원래 제가 쓰던아이디로 하고 이름과 전화번호등 다른것들은 바꿔서 써보았습니다.

이화면을 들어가면 와이어샤크에서 패킷을 하나 잡아냅니다.

서버에 dh_member/join이란곳으로 뭔가 GET요청을 보내네요

그다음에 아이디를 쓰고 중복화인을 눌러보았는데

서버에서 제아이디가 있는지 확인하는 GET요청을 날리고있네요 쿼리까지 다보이고 제아이디가 뭔지도 그대로 보이네요.

이제 중요한 POST요청입니다. 모든 정보를 기입하고 회원가입 요청을 눌렀습니다.

이 주소로 쿼리를 날릴때 패킷안에 뭘 넣어서 보냈는지 까볼게요

보시면 위에서부터 천천히보시면 아이디와 패쓰워드 제 생일 우편주소등등 데이터가 다 들어가있네요 POST요청으로 보내면 보안이 안전하다고 배웠는데 전혀 아니였고 중간에 그래도 뭔가 암호화가 되어있어서 GPT와 상의한결과 Base64로 인코딩된 문자같아서 Base64로 디코딩해보았습니다.

디코딩은 GPT 에게 부탁한다음 결과를 출력해달라고 했습니다.

이렇게 출력을 해줬는데요 보니까 이상한 특수문자같은건 한글로 입력한 부분인데

정확히는 Base64로 인코딩된게 아닌거같습니다.

제가 입력한 이름과 주소가 다르게 출력되었습니다.

하지만 번호나 영문데이터인 아이디 비밀번호는 그대로 출력되는걸 확인할 수 있었습니다.

애당초 번호나 영문은 암호화를 하지 않고 보내고 있었기 때문이죠..

불법사이트중에는 HTTP로 개발한 사이트들이 더러 있는데 그런사이트를 함부로 이용하면

이런 아이디와 비밀번호 주소 번호 다 털리게 되는것입니다.

GPT가 출력한 결과물을 보니 데이터가 어떤구조로 저장하고있는지도 대강 파악할수도 있다고 합니다.

이제 HTTPS로 보호되는 사이트를 방문해볼건데요

네이버로 들어가서 패킷을 잡아내볼게요

일단 와이어샤크로 패킷을 필터링을 하려면 네이버의 아이피를 알아야하기때문에

cmd를 켜고

nslookup www.naver.com이라고 입력하면

이렇게 보여주게되는데 168.126.63.1 이란건 KT에서 제공하는 DNS서버인데 여기서 네이버의 아이피를 보여주는거 같습니다.

아이피가 네개가 뜨고 알리야스로 www.naver.com이라고 출력되는걸 확인하였습니다.

그럼 필터링에 223.130까지는 하면되는데 아이피가 네개라 네이버 아이피의 16비트 서브넷을 모두 필터링해보도록 하였습니다.

필터링은

ip.src == 172.30.1.87 && (ip.dst >= 223.130.0.0 && ip.dst <= 223.130.255.255)

이런식으로 작성하였습니다.

처음 네이버에 들어가게되면

네이버로부터 이런응답을 받네요 ㅎ

그리고 네이버 로그인을 진행해봤는데

로그인버튼을 누르면

일단 프로토콜이 HTTP가 아니라 TLSv1.3이라고 뜨는걸 확인할 수 있네요

그리고 로그인을 할때 제가 서버에 요청을 보낼때 그게 GET요청인지 POST요청인지 못보게 되어있네요

그저 뭔가 로그인요청을했을때 Application Data라고 세개가 날라가는것만 확인할수 있습니다.

패킷을 확인해보면

이패킷을 GPT에게 그대로 보여주면서 이거 어떻게 암호화되어있는지 확인해볼래 라고 질문해보았고

되돌아온 대답은 단지 이 패킷은 TCP프로토콜을 사용하고있다입니다.

아까 페이지에서 패킷에 데이터가 담기는 부분은

이런식으로 HTTP라고 되어있고 네이버의경우 HTTPS를 사용하기때문에

TLS라고 되어있네요

HTTPS를 사용하게되면 이렇게 네가지에 방어를 할수있습니다.

도청 (Eavesdropping):
- HTTP로 전송되는 데이터는 암호화되지 않기 때문에, 중간에 네트워크 트래픽을 감시하는 사람이 데이터를 쉽게 읽을 수 있습니다.
- 예: 로그인 정보, 개인 정보, 금융 정보 등이 도청될 수 있습니다.
중간자 공격 (Man-in-the-Middle Attack):
- HTTP는 데이터를 암호화하지 않기 때문에, 공격자가 중간에 데이터를 가로채서 수정하거나 조작할 수 있습니다.
- 예: 웹 페이지 내용을 변경하여 악성 코드를 삽입하거나, 사용자가 입력한 정보를 탈취할 수 있습니다.
데이터 위변조 (Data Tampering):
- HTTP는 데이터의 무결성을 보장하지 않기 때문에, 전송 중에 데이터가 변경될 수 있습니다.
- 예: 공격자가 전송 중인 파일을 수정하여 악성 코드를 포함시킬 수 있습니다.
피싱 (Phishing):
- HTTP는 서버 인증을 하지 않기 때문에, 사용자는 가짜 웹사이트에 속기 쉽습니다.
- 예: 사용자가 가짜 로그인 페이지에 접속하여 자신의 계정 정보를 입력하게 만들 수 있습니다.

HTTPS를 쓰면 어떤게 좋아지냐

TLS가 해주는일은

암호화:
- HTTPS는 데이터를 암호화하여 전송 중에 도청당하지 않도록 보호합니다.
- 예: 로그인 정보, 개인 정보, 금융 정보 등이 안전하게 전송됩니다.
무결성:
- HTTPS는 데이터가 전송 중에 변경되지 않았음을 보장합니다.
- 예: 파일 다운로드 시 파일이 손상되거나 변조되지 않았음을 확인할 수 있습니다.
인증:
- HTTPS는 서버의 신원을 확인하는 인증서를 사용하여, 사용자가 신뢰할 수 있는 서버와 통신하고 있음을 보장합니다.
- 예: 사용자는 피싱 사이트에 속지 않고, 진짜 웹사이트에 접속하고 있음을 확인할 수 있습니다.

전에 JWT를 공부할때 header, payload, signature로 나뉘어서 세파트로 키가 만들어지는데

마지막 signature를 만들때 key를 통해서 jwt가 변조가 되었는지 안되었는지 판단한다고 공부했었는데

정작 우리가 get,post,put,delete요청을 할때는 변조가되었는지 또 데이터가 움직일때 암호화가 되어서 가는지 아직 몰랐던거 같습니다.

일단 HTTPS를 적용시키려면 SSL과 TLS를 알아야하는데

SSL은(Secure Sockets Layer)라고 하며

TLS는 ( Transport Layer Security) 이라고합니다.

Cloudflare에 설명되어있는걸 정리하면

SSL이란건 쉽게말해서 암호화 기반 인터넷 보안 프로토콜입니다.

인터넷 통신의 개인정보 보호, 데이터 무결성을 보장하기위해 Netscape가 1995년 처음으로 개발

SSL은 현재 사용 중인 TLS 암호화의 전신입니다.

SSL/TLS를 사용하는 웹사이트에는 URL에는 HTTP 대신에 HTTPS가 사용됩니다.

위에서 설명중에 어디서 많이 본듯한게 하나 있는데 Transport Layer?

(OSI 7계층에서 4계층에 해당하고 TCP/IP에서 4계층에 해당하는그 Transport Layer가 맞고 그거의 보안을 강화해준다는 말이 맞다.)

응용 계층 (Application Layer):
- HTTP/HTTPS: 웹 브라우징과 웹 서비스를 위한 프로토콜입니다.
- FTP: 파일 전송 프로토콜로, 파일을 서버와 클라이언트 간에 전송합니다.
- SMTP: 이메일 전송을 위한 프로토콜입니다.
- DNS: 도메인 이름을 IP 주소로 변환하는 시스템입니다.
- DHCP: 네트워크에서 IP 주소를 자동으로 할당하는 프로토콜입니다.
전송 계층 (Transport Layer):
- TCP: 연결 지향 프로토콜로, 데이터의 신뢰성 있는 전송을 보장합니다. 데이터 분할, 전송, 재조립, 오류 검출 및 수정 기능을 제공합니다.
- UDP: 비연결 지향 프로토콜로, 빠른 전송이 필요하지만 오류 수정이 필요 없는 경우에 사용됩니다. 실시간 스트리밍 등에 적합합니다.
- SCTP: 멀티스트림 전송을 지원하며, 전화망과 같은 시스템에서 사용됩니다.
- DCCP: 혼잡 제어를 지원하는 데이터그램 프로토콜입니다.
인터넷 계층 (Internet Layer):
- IP (IPv4, IPv6): 패킷의 주소 지정과 라우팅을 담당합니다. IPv6는 IPv4의 주소 부족 문제를 해결합니다.
- ICMP: 네트워크 상태와 오류를 알리는 메시지를 전송합니다. (예: ping)
- ARP: IP 주소를 물리적 하드웨어 주소(MAC 주소)로 변환합니다.
- IPsec: IP 패킷을 암호화하여 보안을 제공합니다.
네트워크 액세스 계층 (Network Access Layer):
- Ethernet: 유선 LAN 기술로, 물리적 계층과 데이터 링크 계층을 포함합니다.
- Wi-Fi: 무선 LAN 기술로, IEEE 802.11 표준을 따릅니다.
- PPP: 직렬 연결을 통해 데이터를 전송하는 프로토콜입니다.
- MPLS: 다양한 네트워크 프로토콜을 효율적으로 전달하기 위한 데이터 전달 메커니즘입니다.
- LTE/5G: 최신 모바일 네트워크 기술로, 고속 데이터 전송을 지원합니다.

SSL/TLS는 왜 중요할까

원래는 웹 상의 데이터는 메세지를 가로채면 누구나 읽을수 있도록 일반 텍스트로 다 보였는데

SSL로 암호화하여 아무도 못보게 하는것입니다.

그럼 SSL과 TLS는 똑같냐?

SSL은 TLS의 이전 프로토콜이라고 생각하면됩니다.

SSL은 1995년에 만들어졌고 TLS는 SSL을 이용하여 1999년에 만들어졌다라고 생각하면 될거같습니다.

이때 TLS가 만들어질때 SSL을 만들었던 넷스케이프가 빠지면서 소유권이 넘어갔습니다.

SSL 3.0버전과 TLS의 첫버전은 거의 비슷했다.

이렇게 긴밀하게 연계되어 있어서 두 용어가 혼합되어 사용되는 경우가 많습니다.

TLS를 아직 SSL이라고 부르기도 하고 SSL의 인지도가 너무 높아서 SSL/TLS 암호화라고 부르는 경우도 많다고 합니다.

SSL은 지금 최신상태입니까?

1996년에 넷스케이프가 3.0으로 업데이트한이후 그대로라서 사용하면 안됩니다.

인터넷에 SSL암호화라고 부르는데 이건 다 TLS암호화를 이야기하는거라고 생각하면 됩니다.

SSL 작동과정

SSL 핸드셰이크 과정이라고 합니다.

1. 클라이언트 헬로(Client Hello)

클라이언트가 서버에 연결 요청을 보냅니다.
클라이언트는 지원하는 SSL버전, 암호화 방법, 임의의 데이터(난수)를 서버에 보냅니다.

2. 서버 헬로(Server Hello)

서버는 클라이언트의 요청에 응답합니다.
서버는 SSL버전, 암호화 방법, 임의의 데이터(난수), 서버인증서(공개키 포함)를 클라이언트에 보냅니다.

3. 서버 인증 및 키 교환

서버는 클라이언트에게 자신의 신원을 증명하기 위해 인증서를 보냅니다.
클라이언트는 인증서를 검증합니다.

4. 클라이언트 키 교환(Client Key Exchange)

클라이언트는 프리마스터 시크릿(pre-master secret)을 생성하고 서버의 공개키로 암호화하여 서버에 보냅니다.

5. 세션 키 생성:

서버와 클라이언트는 프리마스터 시크릿을 바탕으로 대칭 키 (세션 키)를 생성합니다.

6. 암호화 통신 시작

클라이언트와 서버는 대칭 키를 사용하여 데이터를 암호화하고 전송합니다.

여기서 이상한점

왜? 클라이언트가 서버를 검증하는거지?

3번에 서버 인증 및 키 교환을 보면

서버가 나 진짜진짜 네이버에요라고 인증서를 클라이언트에게 보내고 클라이언트는 인증서를 검증하고 있다.

??????

인증서는 검증된 인증 기관(CA)에게 발급을 받을수있다! 그러므로 그 사이트를 발급해준 기관이 인증을 해주고 TLS를 발급해준거다.

이렇게되면 만약 내가 네이버를 통해서 검색한다음 KB국민은행사이트를 들어가기전까지 그건 아주 신뢰된 사이트에서 이동한거고 KB국민은행 사이트도 TLS인증서가 있다면 그 은행사이트도 신뢰할수 있기때문에 나는 안심하고 돈을 입금하고 찾을 수 있을것이다.

즉 TLS로 신뢰할 수 있는 통신을 보장하고, 피싱 사이트를 방지하고, 데이터를 암호화하여 더욱 안전한 금융거래를 할수 있다.

TLS와 SSL의 차이점

TLS 1.0 은 원래 SSL3.1이 개발될때 Netscape가 손을떼면서 이름이 바뀜

즉. 처음 시작은 같은거였다고 생각하면됨

비즈니스와 웹 응용 프로그램에서 왜 TLS 프로토콜을 사용해야 합니까?

TLS 암호화는 데이터 유출 및 기타 공격으로부터 웹 애플리케이션을 보호하는 데 도움이 될 수 있습니다. 오늘날 TLS로 보호되는 HTTPS는 웹 사이트의 표준 관행입니다. Google Chrome 브라우저는 점차적으로 비HTTPS 사이트를 엄중 단속했으며, 다른 브라우저도 그 뒤를 따랐습니다. 일상적인 인터넷 사용자들은 HTTPS 자물쇠 아이콘이 없는 웹 사이트를 더욱 경계합니다.

TLS는 무엇을 합니까?

TLS 프로토콜은 암호화, 인증, 무결성이라는 세 가지 주요 요소를 달성합니다.

암호화: 제3자로부터 전송되는 데이터를 숨깁니다.
인증: 정보를 교환하는 당사자가 요청된 당사자임을 보장합니다.
무결성: 데이터가 위조되거나 변조되지 않았는지 확인합니다.

TLS 1.3 작동 순서

클라이언트 헬로(Client Hello):
- 클라이언트가 서버에 연결 요청을 보냅니다.
- 지원하는 TLS 버전, 암호화 방법, 임의의 데이터(난수)를 서버에 보냅니다.
서버 헬로(Server Hello):
- 서버는 클라이언트의 요청에 응답합니다.
- TLS 버전, 암호화 방법, 임의의 데이터(난수), 서버 인증서를 클라이언트에 보냅니다.
서버 인증 및 키 교환:
- 서버는 자신의 신원을 증명하기 위해 인증서를 보냅니다.
- 클라이언트는 인증서를 검증합니다.
클라이언트 키 교환(Client Key Exchange):
- 클라이언트는 프리마스터 시크릿을 생성하고 서버의 공개키로 암호화하여 서버에 보냅니다.
세션 키 생성:
- 서버와 클라이언트는 프리마스터 시크릿을 바탕으로 대칭 키(세션 키)를 생성합니다.
암호화 통신 시작:
- 클라이언트와 서버는 대칭 키를 사용하여 데이터를 암호화하고 전송합니다.

SSL과 TLS의 작동순서가 같다..

좀 찾아보니 조금 다른부분이 있는데

3번 서버 인증 및 키교환 부분에서 TLS 는 서버가 클라이언트의 인증을 요청할 수도 있다고 한다.

SSL에 비해서 TLS의 개선점

보안 강화:
- TLS는 SSL에서 발견된 여러 보안 취약점을 해결했습니다. 예를 들어, TLS는 MAC(Message Authentication Code)를 개선하고, 해시 함수로 MD5를 사용하지 않으며, 키 생성 과정에서 더 강력한 암호화 알고리즘을 사용합니다.
핸드셰이크 메시지 구조:
- TLS는 핸드셰이크 메시지 구조를 개선하여 더 많은 정보를 포함할 수 있도록 했습니다. 예를 들어, ClientHello 메시지에는 지원하는 암호화 스위트 리스트와 함께 확장(extension) 필드가 추가되었습니다.
암호화 알고리즘:
- TLS는 더 강력한 암호화 알고리즘을 지원합니다. TLS 1.2에서는 AES(Advanced Encryption Standard)와 같은 현대적인 암호화 알고리즘을 도입하였습니다.
레코드 프로토콜:
- TLS는 레코드 프로토콜에서 더 나은 보안과 성능을 제공하기 위해 여러 가지 개선을 했습니다. 예를 들어, TLS는 CBC(Cipher Block Chaining) 모드 대신 GCM(Galois/Counter Mode)을 사용할 수 있습니다.

그래서 어떻게 내 프로젝트에 적용시키면 되냐

아 또 빡치는게 이게 Cerbot이라는걸 설치해야되는데 리눅스계열에서 많이 사용되서 윈도우에서는 좀 복잡해짐

Windows에서 Certbot 설치 및 사용

Windows Subsystem for Linux (WSL) 설치
- WSL을 사용하면 Windows에서 Linux 환경을 사용할 수 있습니다.
- WSL을 설치하려면 PowerShell을 관리자 권한으로 실행하고 다음 명령을 실행합니다.
- powershell wsl --install
- 설치가 완료되면, 시스템을 재부팅합니다.
- 재부팅 후, Microsoft Store에서 Ubuntu 또는 다른 Linux 배포판을 설치합니다.
WSL에서 Certbot 설치
- WSL 터미널을 열고, Certbot을 설치합니다.
```
sudo apt-get update
sudo apt-get install certbot
```
인증서 발급
- Certbot을 사용하여 인증서를 발급받습니다. 다음 명령을 사용하여 인증서를 발급받습니다.
- sudo certbot certonly --standalone -d yourdomain.com
- 이 명령은 인증서를 /etc/letsencrypt/live/yourdomain.com/ 경로에 저장합니다.
Windows로 인증서 파일 복사
- 발급받은 인증서 파일을 Windows 파일 시스템으로 복사합니다.
- WSL에서 Windows 파일 시스템은 **/mnt/c/**에 마운트되어 있습니다.
- 예를 들어, 인증서 파일을 C:\\certs\\ 디렉터리로 복사할 수 있습니다.
- sudo cp /etc/letsencrypt/live/yourdomain.com/privkey.pem /mnt/c/certs/ sudo cp /etc/letsencrypt/live/yourdomain.com/fullchain.pem /mnt/c/certs/
Node.js와 Express에서 HTTPS 설정

Windows 파일 시스템에 복사한 인증서 파일을 사용하여 Node.js와 Express 애플리케이션에서 HTTPS를 설정합니다.

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

const app = express();

// Windows 파일 시스템에 복사한 인증서 경로 설정
const sslKeyPath = 'C:\\\\certs\\\\privkey.pem';
const sslCertPath = 'C:\\\\certs\\\\fullchain.pem';

const sslOptions = {
  key: fs.readFileSync(sslKeyPath),
  cert: fs.readFileSync(sslCertPath)
};

app.get('/', (req, res) => {
  res.send('Hello, HTTPS!');
});

https.createServer(sslOptions, app).listen(443, () => {
  console.log('HTTPS Server running on port 443');
});

TLS는 웹 응용 프로그램 성능에 어떻게 영향을 미칩니까?

TLS의 최신 버전은 웹 응용 프로그램 성능에 거의 영향을 미치지 않습니다.

TLS 연결을 설정하는 데 수반되는 복잡한 프로세스 때문에 로드 시간과 계산 능력이 소모되어야 합니다. 데이터가 전송되기 전에 클라이언트와 서버는 왔다 갔다 몇 번 커뮤니케이션해야 하며, 이는 클라이언트와 서버 모두를 위한 메모리뿐만 아니라 웹 응용 프로그램을 위한 귀중한 밀리세컨드의 로딩 시간을 소모합니다.

그러나 대신에 TLS Handshake가 생성한 잠재적인 지연을 완화하는 것을 돕는 기술이 있습니다. 하나는 TLS Handshake가 완료되기 전에 서버와 클라이언트가 데이터 전송을 시작하도록 하는 TLS False Start입니다. TLS를 빠르게 하기 위한 또 다른 기술은 이전에 커뮤니케이션한 적이 있는 서버와 클라이언트가 간략화된 Handshake를 사용하도록 허용하는 TLS Session Resumption입니다.

이러한 개선 사항은 TLS를 로딩 시간에 현저하게 영향을 미쳐서는 안 되는 매우 빠른 프로토콜로 만드는 데 도움을 주었습니다. TLS와 연관된 계산 비용은 오늘날 표준에 따르면 거의 무시해도 좋은 정도입니다.

2018년에 발표된 TLS 1.3은 TLS를 더 빠르게 만들었습니다. TLS 1.3의 TLS Handshake는 몇 밀리세컨드로 프로세스를 단축하며 2회 왕복 대신 1회 왕복(또는 왔다 갔다하는 커뮤니케이션)만을 요구합니다. 사용자가 전에 웹 사이트에 연결한 적이 있으면, TLS Handshake는 0회 왕복을 할 수 있으며, 이는 속도를 더 빠르게 할 수 있습니다.

'웹 보안' 카테고리의 다른 글

웹 보안 방어 정리 (0)	2024.10.26

HTTPS를 왜 써야될까