웹을 안전하게 지켜주는 HTTPS
7.1 HTTP의 약점
- 평문(암호화 하지 않은) 통신이기 때문에 도청 가능
- 통신 상대를 확인하지 않기 때문에 위장 가능
- 완전성을 증명할 수 없기 때문에 변조 가능
- 특정 웹 서버나 특정 웹 클라이언트의 구현상의 약점
- Java나 PHP 등으로 구축한 웹 애플리케이션 취약성 등
7.1.1 평문이기 때문에 도청 가능
HTTP는 자신을 암호화하는 기능이 없어 통신 전체가 암호화 되지 않기 때문에 평문으로 HTTP 메세지를 보냄.
TCP/IP는 도청 가능한 네트워크
TCP/IP 구조의 통신 내용은 전부 통신 경로의 도중에 엿볼 수 있음. 같은 세그먼트의 통신을 도청하는 것은 네트워크 상을 흐르고 있는 패킷을 수집하는 것만으로 도청할 수 있음.
암호화로 도청을 피하다
1) 통신 암호화
HTTP는 암호화 구조는 없지만 SSL(Secure Socket Layer)이나 TLS(Transport Layer Security)라는 다른 프로토콜을 조합해 HTTP 통신 내용을 암호화할 수 있음.
2) 콘텐츠 암호화
HTTP 메세지에 포함되는 콘텐츠만 암호화. 웹 서비스에서 주로 이용되는 방법.
7.1.2 통신 상대를 확인하지 않기 때문에 위장 가능
HTTP를 사용한 리퀘스트나 리스폰스에서는 통신 상대를 확인하지 않음. 누구나 리퀘스트를 보낼 수 있음. 상대를 확인하지 않는 점이 약점.
HTTP에서는 통신 상대를 확인할 수는 없지만 SSL로 상대를 확인할 수 있음. SSL은 암호화뿐만 아니라 상대를 확인하는 수단으로 증명서를 제공.
7.1.3 완전성을 증명할 수 없기 때문에 변조 가능
완전성이라는 정보의 정확성.
HTTP가 완전성을 증명할 수 없다는 것은 만약 리퀘스트나 리스폰스가 발신된 후, 상대가 수신할 때까지 사이에 변조되었다고 하더라도 이 사실을 알 수 없다는 것.
그렇다면 변조를 방지하기 위해, 확실하면서 편리한 방법은 현재로서 존재하지 않음. 자주 사용하는 방법은 MD5나 SHA-1 등의 해시 값을 확인하는 방법과 파일의 디지털 서명을 확인하는 방법.
7.2 HTTP + 암호화 + 인증 + 완전성 보호 = HTTPS
7.2.1 HTTP에 암호화와 인증과 완전성 보호를 더한 HTTPS
HTTPS(HTTP Secure) : HTTP에 암호화나 인증 등의 구조를 더한 것
웹 페이지의 로그인이나 쇼핑의 결제 화면 등에서 사용.
7.2.2 HTTPS는 SSL의 껍질을 덮어쓴 HTTP
HTTPS는 새로운 애플리케이션 계층의 프로토콜이 아님. 통신을 하는 소켓 부분을 SSL(Secure Socket Layer)이나 TLS(Transport Layer Security)라는 프로토콜로 대체하고 있을 뿐.
SSL을 사용함으로써 HTTP는 HTTPS로서 암호화와 증명서와 완전성 보호를 이용. SSL은 현재 세계 어느 곳곳에서도 널리 사용되고 있는 네트워크 보안 기술.
7.2.3 상호간에 키를 교환하는 공개키 암호화 방식
SSL은 공개키 암호화 방식을 채용. 현대의 암호화는 알고리즘은 공개, 키는 비공개.
공통키 암호의 딜레마
암호화/복호화 모두 같은 키 사용. 따라서, 상대방에게 키를 넘겨줘야하는 데 어떻게 안전하게 넘길까? 키를 보내면 도청 가능성이 있고, 키를 보내지 않으면 복호화도 못함.
애초에 키를 안전하게 보낼 수 있다면 틀림없이 데이터도 안전하게 보낼 수 있음.
두 개의 키를 사용하는 공개키 암호
공개키 암호에서는 서로 다른 두 개의 키 페어(쌍)을 사용. 한쪽은 비밀키(private key)라 부르고 다른 한 쪽은 공개키(public key)라 부름.
공개키 암호를 사용한 암호화는 암호를 보내는 측이 상대의 공개키를 사용해 암호화 함. 그리고 암호화된 정보를 받아들인 상대는 자신의 비밀키를 사용해 복호화 함.
HTTPS는 하이브리도 암호 시스템
HTTPS는 공통키 암호와 공개키 암호의 양쪽 성질을 가진 하이브리드 암호 시스템. 키를 교환하는 곳에서는 공개키 암호를 사용하고 그 후의 통신에서 메세지를 교환하는 곳에서는 공통키 암호를 사용.
7.2.4 공개키가 정확한지 아닌지를 증명하는 증명서
공개키의 문제점은 그 키가 진짜인지 아닌지를 증명할 수 없다는 점.
인증기관(CA:Certificate Authority)와 그 기관이 발행하는 공개키 증명서를 이용.
조직의 실제성을 증명하는 EV SSL 증명서
EV SSL 증명서는 서버가 올바른 통신 상대임을 증명하는 것 이외에도 상대방이 실제로 있는 기업인지를 확인.
클라이언트를 확인하는 클라이언트 증명서
서버가 통신하고 있는 상대가 의도한 클라이언트인 것을 증명.
다만, 유저가 클라이언트 증명서를 유료로 구입해야하고, 인스톨 작업이 있다는 문제점.
7.2.5 안전한 통신을 하는 HTTPS의 구조
SSL과 TLS
HTTPS에서는 SSL(Secure Socket Layer)과 TLS(Transport Layer Security)라는 두 개의 프로토콜을 사용.
현재는 SSL3.0, TLS1.0이 주류.
SSL은 느리다?
- 통신 속도가 떨어짐
- CPU나 메모리 등의 리소스를 다량으로 소비함으로써 처리가 느려짐.
SSL 엑셀레이터라는 하드웨어(appliance 서버)를 사용해서 문제를 해결함.
무선 랜 이해하기
무선 랜의 구조
무선 랜
무선 랜은 랜 케이블을 사용하지 않고 눈에 보이지 않는 전파를 이용하여 무선으로 컴퓨터를 서로 연결.
무선 액세스 포인트(Wireless Access Point,WAP)와 무선 클라이언트(컴퓨터나 스마트폰 등)로 구성.
장점
- 케이블이 지저분하게 엉키거나 걸리적거리지 않음.
- 랜 케이블이 닿지 않는 곳에도 통신 가능.
단점
- 유선보다 속도가 불안정함
- 전파가 약하면 연결이 잘 안됨
- 유선 랜에 비해 통신 내용이 해킹될 위험이 높음.
컴퓨터가 무선 액세스 포인트와 통신하려면 무선 랩 칩(chip)과 무선 랜 어댑터(adapter)가 필요함.
무선 랜 어댑터에는 USB 포트에 꽂아 사용하는 USB 메모리 방식 어댑터와 컴퓨터 카드 방식 어댑터가 있음.
집에서 사용하는 무선 공유기에는 무선 액세스 포인트 기능이 있음.
인프라스트럭처 방식과 애드혹 방식
무선 랜을 연결하는 방식으로는 인프라스트럭처 방식과 애드혹 방식이 있음.
인프라스트럭처 방식
무선 액세스 포인트를 통해 통신하는 방식, 주로 사용.
애드혹 방식
무선 클라이언트끼리 직접 통신하는 방식
무선 랜 규격
무선 랜은 IEEE802.11 규격을 준수하는 기기로 구성.
무선 랜을 구성하는 장비 중, 무선 액세스 포인트를 무선 공유기 또는 무선 AP라 부름.
SSID의 구조
SSID
무선 액세스 포인트와 무선 클라이언트를 연력하려면 혼선을 피하기 위해 SSID(Service Set IDentifier)라는 액세스 포인트의 고유 이름을 사용. 그리고, 네트워크 이름, 인증, 암호화, 암호화 키를 설정.
채널
무선 액세스 포인트와 무선 클라이언트 사이의 거리가 멀수록 전파가 약해져 접속이 잘 안되거나 통신 속도가 느려짐. 따라서, 무선 액세스 포인트를 여러 대 설치해야 함.
무선 랜은 여러 기기를 동시에 연결할 수 있도록 주파수 대역을 분할하는데, 그 주파수 대역을 채널이라고 함.
무선 공유기 A와 무선 공유기 B는 다른 채널을 설정해야 함.
다른 채널로 설정하면 전파는 겹치지만 주파수가 겹치지 않아 서로 간섭이 일어나지 않아 통신 속도도 떨어지지 않음.
※ IEEE802.11b와 IEEE802.11g는 서로 다른 채널인 1ch와 2ch이더라도 일부에서 같은 주파수를 사용하기 때문에 주의.
