[Network] 계층 별 프로토콜 (2)
Updated:
SSH, HTTPS, DNS는 안전한 통신을 위한 프로토콜입니다. 원격 접속과 웹 통신을 암호화하고, 도메인을 IP로 연결하여 인터넷을 안전하고 편리하게 만드는 핵심 기술의 차이를 설명합니다.
프로토콜
데이터를 교환하고 통신하기 위해 컴퓨터간 상호 약속된 규칙의 집합
Telnet(Telecommunication Network Protocol)
개념
- 원격 호스트에 접속하기 위해 사용하는 프로토콜
- 네트워크를 통해 다른 컴퓨터의 명령창을 사용
- 인터넷 초기 원격 접속 기술로 사용
동작 방식
- 클라이언트-서버 구조 23번 포트 사용
특징
- 대부분의 운영체제 지원
- 실시간 양방향 통신
- 간단한 프로토콜
단점
- 모든 데이터를 평문으로 전송
- ID/PWD 노출
- 세션 전체가 도청될 가능성
- 중간자 공격
- 데이터가 변조될 수 있음
이를 보완하기 위해 나온 개념이 SSH임.
SSH(Secure shell)
개념
- 원격 호스트에 접속하기 위해 사용하는 프로토콜
- 모든 통신이 암호화됨(데이터, 비밀번호, 명령어 등)
특징
- 22번 포트를 사용
- 비밀번호 인증과 공개키/비밀키 인증 방식 존재
- 주로 공개키/비밀키 방식을 사용
- 포트 포워딩으로 안전한 터널 생성
- telnet, ftp, rcp, rexec 등 기존 비보안 도구를 대체
- 세션 관리 가능
- 다중 채널, Keep-alive 속성 등
- 대부분의 운영체제 지원할 뿐만 아니라 IoT 기기에서도 사용 가능
단점
- 복잡한 키 관리
- 키 생성, 배포, 순환, 폐기
- 키 분실 시 접근이 불가능하며 백업되어있지 않다면 영구 잠금
- 방화벽 차단 혹은 NAT 장비에서 포트 포워딩 설정 필요
- 인터넷에 노출된 SSH 서버는 공격 대상 → Bastion host
Telnet vs SSH
| 구분 | Telnet | SSH |
|---|---|---|
| 보안성 | 평문 전송, 도청 위험 | 암호화 통신, 안전함 |
| 인증 | 기본적인 ID/PW만 | 비밀번호, 공개키, 2FA 등 |
| 포트 | 23번 (표준) | 22번 (표준) |
| 리소스 사용 | 매우 적음 | 암호화로 인한 오버헤드 |
| 설정 복잡도 | 매우 간단 | 키 관리 등 복잡 |
| 호환성 | 모든 시스템 지원 | 일부 구형 시스템 제한 |
| 디버깅 | 평문으로 쉬운 분석 | 암호화로 분석 어려움 |
| 파일 전송 | 별도 프로토콜 필요 | SCP, SFTP 내장 |
| 터널링 | 지원 안함 | 포트 포워딩 지원 |
| 현재 사용 | 보안상 거의 사용 안함 | 표준 원격 접속 도구 |
HTTP(Hypertext Transfer Protocol)
개념
- HyperText(한 문서에서 다른 문서로 즉시 접근할 수 있는 텍스트) 기반 정보를 주고 받을 수 있는 프로토콜
- Web에서 정보를 주고받기 위함
특징
- 80번 포트를 사용
- Request/Response 기반 클라이언트-서버 모델
- Stateless 기반 요청간 상태를 저장하지 않음
- 헤더를 통해 인증, 세션 등 다양한 기능으로 확장 가능
- 운영체제나 하드웨어에 관계없이 사용 가능
- 텍스트 기반으로 디버깅과 모니터링이 용이
- 에러 코드 + 텍스트
- 200 - OK, 400 - Bad request, 404 Resource not found
- 에러 코드 + 텍스트
- 메소드 기반 요청 파악 용이(GET/POST/PUT/DELETE)
단점
- 모든 데이터가 평문으로 전송되며 데이터 변조 여부 확인 어려움
- 패스워드, 개인정보같은 민감 정보가 그대로 노출됨
- 상태 정보를 유지하기 위한 별도의 로직 구성
- 쿠키, 세션 등 외부 저장소 의존
- HTTP 버전에 따라 연결 오버헤드, 요청 블로킹이 발생
- 매 요청간 TCP Connection 생성 (HTTP/1.0)
- 대용량 요청 지연 시 뒤 요청들도 대기 (HTTP1.1)
HTTPS(HyperText Transfer Protocol Secure)
개념
- HTTP를 확장하여 데이터를 안전하게 전송하는 프로토콜
- SSL/TLS 기반의 기밀성, 무결성, 전송/수신자 인증을 보장함
특징
- 443번 포트를 사용
- 통신을 시작하기 전 디지털 인증서를 통해 서버의 신원을 검증
- CA(Certificate Authority)에서 발급한 신뢰할 수 있는 인증서 사용
- 민감한 정보, 데이터 무결성 보장
- TLS 기반 인증서 교환 메커니즘
- 현재 TLS v1.3 기반의 메커니즘을 주로 사용
- 지속적으로 개선되고 있음
- 현재 TLS v1.3 기반의 메커니즘을 주로 사용
단점
- 인증서 관리 필요
- 인증서 발급/설치/갱신/삭제 등 추가 리소스 관리
- 인증서 만료시 접근이 차단될 수 있음
- Private CA 를 사용하는 경우 더 복잡함
- 도메인 별 인증서 발급
- 인증서 발급/설치/갱신/삭제 등 추가 리소스 관리
HTTP vs HTTPS
| 구분 | HTTP | HTTPS |
|---|---|---|
| 보안 | 평문 전송, 보안 없음 | SSL/TLS 암호화 |
| 포트 | 80 | 443 |
| 인증서 | 불필요 | SSL 인증서 필수 |
| 성능 | 빠름 | HTTP 대비 느림 (암호화 처리) |
| 데이터 보호 | 스니핑 위험 | 암호화로 보호 |
| 서버 인증 | 없음 | 디지털 인증서로 검증 |
| 브라우저 표시 | 경고 표시 | 자물쇠 아이콘 |
| SEO | 불리 | 우선순위 |
| 비용 | 무료 | 인증서 관리 비용 |
| 사용 권장 | 권장하지 않음 | 현재 웹 표준 |
DNS(Domain Name System)
개념
- 도메인 네임 시스템에서 클라이언트와 서버 간 통신을 위한 응용 계층 프로토콜
- 도메인 이름과 IP 주소 간 매핑 정보를 교환
- 숫자 IP 주소 대신 호스트 이름으로 접속할 수 있게 됨
특징
- UDP 53번 포트를 사용하나 구성에 따라 TCP도 사용 가능
- UDP 기반 경량 프로토콜로 빠른 응답
- 패킷은 Header, Question, Answer, Authority, Additional 구조
- Header - 제어정보, 패킷의 정보를 가짐
- Question - 도메인명, 레코드 타입을 가짐
- A 레코드 → 도메인의 IPv4 주소
- AAAA 레코드 → 도메인의 IPv6 주소
- CNAME(Canonical NAME) 레코드 → 도메인 이름 별칭
- www.example.com → example.com
- MX, TXT 레코드 → 메일 관련 레코드
- NS 레코드 → 실제 DNS 레코드를 갖고 있는 서버
- 서버 다운을 방지하여 여러 개의 NS 레코드가 제공됨
- SOA → 도메인 또는 영역에 대한 중요한 정보를 저장
- 관리자의 이메일, 마지막 업데이트 시간, 레코드 새로고침 대기 시간 등
- Answer - DNS 서버가 Question에 답변을 제공
- Authority - 요청, 상위 도메인을 관리하는 네임서버 정보 제공
- Additional - 레코드 타입에 따라 추가 정보 제공
- TTL 기반의 데이터 캐싱 지원
- IP 주소가 변경되어도 도메인 이름은 유지되어 서버 이전이나 확장 용이
단점
- UDP 기반 응답이 손실될 가능성
- 잘못된 정보가 캐싱되면 TTL이 만료될 때까지 잘못된 결과 제공
- 가용성 및 단일 장애점 관리 필요
- 네임서버 장애시 도메인을 통한 접근 어려움
- 처음 접근하는 도메인은 루트 서버부터 시작
- 콜드 스타트 문제