- HTTP를 안전하게 만들기
- 디지털 암호학
- 대칭키 암호법
- 공개키 암호법
- 디지털 서명
- 디지털 인증서
- HTTPS의 세부사항
- 진짜 HTTPS 클라이언트
- 프락시를 통한 보안 트래픽 터널링
1. HTTP를 안전하게 만들기
이전 장에서 배운 인증/인가, 메시지 무결성 방법들은 충분히 강력하지 않다.
따라서 더 빡센 디지털 암호화 기술을 써야한다. 그게 이번 장에서 배울 내용ㅇㅇ
아내 요구조건을 모두 충족시킬 수 있는 보안기술이 필요하다.
-서버 인증
-클라이언트 인증
-무결성(데이터 위조 방지)
-암호화
-효율(빨라야 함)
-편재성(Ubiquity)
-관리상 확장성
-적응성
-사회적 생존성(사회,문화,정치적 요구 만족 시켜야 함)
1-1. HTTPS
HTTPS는 HTTP를 안전하게 만들어 주는 것들 중 가장 인기 있음.
Netscape Communications Corporation에서 만들었다.
HTTPS를 쓰면 모든 request-response 데이터는 네트워크로 보내지기 전 암호화된다.
HTTPS는 HTTP 하부에 전송 레벨 암호 보안 계층을 제공한다.
이 보안 계층은 안전 소켓 계층(Secure Sokets Layer, SSL), 혹은
그를 계승한 전송 계층 보안(Transport Layer Security, TLS)를 이용하여 구현된다.
(SSL과 TLS는 매우 비슷해서 이 책에선 양쪽 모두를 표현하는 말로 SSL을 사용한다.)
(사진첨부)
빡센 인코딩/디코딩 작업은 대부분 SSL library에서 일어나기에, HTTPS써도 우리가 할 일은 딱히 없다. TCP 입/출력 호출을 SSL 호출로 대체하고, 보안 정보 설정하고, 그외 몇가지만 더 해주는 정도?
2. 디지털 암호학
SSL, HTTPS에 이용되는 암호 인코딩 기법에 대해 약간의 배경지식을 배우는 챕터다! 야호
(이미 아는 사람은 건너 뛰어도 된다고 한다)
-암호: 텍스트를 아무나 읽지 못하도록 인코딩하는 알고리즘
-키: 암호의 동작을 변경하는 숫자로 된 매개변수
-대칭키 암호 체계: 인코딩/디코딩에 같은 키를 사용하는 알고리즘
-비대칭키 암호 체계: 위와 반대
-공개키 암호법: 비밀 메시지를 전달하는 수백만 대의 컴퓨터를 쉽게 만들 수 있는 시스템
-디지털 서명: 메시지가 위/변조 되지 않았음을 입증하는 체크섬
-디지털 인증서: 신뢰할 만한 조직에 의해 서명되고 검증된 신원 확인 정보
2.1 주절주절
호랑이 담배피던 시절 암호 방법
(사진 첨부)
키가 있는 암호의 등장
(사진 첨부)
디지털 암호
-더 복잡한 암호화가 가능해졌다.
-평문 + 인코딩 함수 + 디지털 인코딩 키 = 암호문
-암호문 + 디코딩 함수 + 디지털 디코딩 키 = 평문
3 대칭키 암호법
대칭키: encoding key = decoding key
대칭키 알고리즘: DES, Triple-DES, RC2, RC4
3-1. 키 길이와 열거 공격(Enumeration Attack)
-대부분 encoding/decoding 알고리즘은 알려져 있으므로, key는 절대 노출되면 안된다.
-좋은 알고리즘은 해킹하기 위해 우주에 존재하는 모든 가능한 키 값을 대입해야만 하는 알고리즘이다.
-무차별로 모든 키 값을 대입해 보는 것을 열거 공격(Enumerations Attack)이라 한다.
-키가 몇 비트인지가 중요하다.
8비트 키라면 256가지 값이 가능,
40비트라면 2의 40승(약 1조)가지가 가능하고,
128비트라면 약 340,000,000,000,000,000,000,000,000,000,000,000,000가지의 값이 가능하다.
-40비트면 보안이 별로 안중요한 업무에서는 충분히 가능하지만, 초당 수십억 번의 계산이 가능한 오늘날엔 쉽게 털릴 수 있다.
-반면, 128비트는 매우 안전한 것으로 간주된다. 암호 기반 보안에서 키의 길이는 엄청 중요하다.
(사진첨부)
3-2. 공유 키 발급하기
대칭키 방식의 단점은 양쪽 다 공유 키 가져야 한다는 것이다.
만약 100명과 대화하려면, 키 100개를 관리해야 한다. 하여튼 키 관리가 복잡한게 단점이다.
4 공개키 암호법
한 쌍의 호스트가 하나의 키(인코딩-디코딩 가능한)를 공유하는 방법 대신, 공개키 암호 방식은 두개의 비대칭 키를 사용한다. one for encoding, one for decoding.
an encoding key is public, 모두가 볼 수 있다. ->공개키 방식이라 불리는 이유.
하지만 decoding key는 호스트 만이 알 고 있다.
노드 X는 자신의 인코딩 키 ex를 공개적으로 배포할 수 있다.
이를 통해 노드 x에게 메세지를 보내려면 누구나 똑같은 공개키를 사용할 수 있고, 키가 폭발적으로 증가하는 현상을 피할 수 있다.
-디코딩 키는 X만이 가지고 있기에 X만 디코딩 가능하다.
everyone can encode, only x can decode.
-public-Key Infrastructure, PKI표준화 작업이 25년 넘게 진행중인 상태였다고 한다.
4-1. RSA
가장 빡세고 유명한 공개키 암호 체계중 하나는 MIT에서 발명하고 RSA data security에서 상용화된 RSA 알고리즘이다.
설명이 긴데 여하튼 이거 뚫기 어렵다는 말ㅇㅇ.
-공개키
-가로채서 얻은 암호문의 일부
-메시지와 그것을 암호화환 암호문
위 세개를 가지고 있따 해도 비밀키 없이는 메시지 해석을 못해야 좋은 키다. RSA는 이를 만족시킴.
-개인키를 찾아내는 것은 컴싸 모든 분야에서 가장 어려운 문제 중 하나라고 알려진 큰 소수를 계산하는 문제만큼 어렵다고 한다. 이거 해내면 스위스 은행 계좌 다 뚫기 가능.
-RSA 이해하려면 빡센 수학 이해해야되므로 여기까지 하자. 몰라도 쓸수는 있다.( 이 책에서 이런 말을 하다니 어지간히 어렵긴 한듯)
5. 디지털 서명
누가 메세지를 썼는지, 그 메세지가 위조되진 않았는지 증명하기 위해 서명 사용.
특히 인터넷 보안 인증서에서 중요하다.
디지털 서명은 메시지에 붙어있는 특별한 암호 체크섬이다.
체크섬 ( checksum )은 중복 검사의 한 형태로, 오류 정정을 통해, 공간(전자 통신)이나 시간(기억 장치) 속에서 송신된 자료의 무결성을 보호하는 단순한 방법이다.
오류 검출 방식의 하나. 메시지에 포함된 비트 수에 기반한 수칫값을 전송 메시지에 추가하여 전송함으로써 오류를 검출한다
내용이 좀 빡세다. 그림 + 책 내용 그대로 읽으면 얼추 이해되긴 함.
-노드 A는 가변 길이 메시지를 정제하여 고정된 길이의 요약(digest)으로 만든다.
-노드 A는 그 요약에, 사용자의 개인 키를 매개변수로 하는 '서명' 함수를 적용한다. 오직 그 사용자만이 개인 키를 알고 있기 때문에, 올바른 서명 함수는 서명자가 소유자임을 보여준다. 그럼 14-10에서 우리가 서명 함수로 디코더 함수 D를 사용한 이유는, 그 함수가 사용자의 개인 키에 관련되어 있기 때문이다.
-한번 서명이 계산되면, 노드 A는 그것을 메시지의 끝에 덧붙이고 메시지와 그에 대한 서명 둘 다를 노드 B에게 전송한다.
-메시지를 받은 노드 B가, 만약 그 메시지를 쓴 것이 정말로 A이며 동시에 위조되지도 않았다는 것을 확인하고 싶다면 서명을 검사할 수 있다. 노드 B는 개인 키로 알아보기 어렵게 변형된 서명에 공개키를 이용한 역함수를 적용한다. 만약 풀어낸 요약이 노드 B가 갖고 있는 버전의 요약과 일치하지 않는다면, 메시지가 송신 중에 위조되었거나 아니면 발송자가 노드 A의 개인 키를 갖고 있지 않은 것이다(따라서 메시지를 쓴 것은 노드 A가 아니다).
(사진 첨부)
6. 디지털 인증서
-인터넷상의 신분증
-신뢰할 수 있는 기관으로부터 보증 받은 사용자나 회사에 대한 정보를 담고 있다.
인증서의 내부
-인증 기관에 의해 디지털 서명된 정보의 집합.
-대상의 이름(사람, 서버, 조직 등)
-유효 기간
-인증서 발급자(보증자)
-인증서 발급자의 디지털 서명
-사용된 서명 알고리즘에 대한 서술적 정보
-공개키(옵션)
(사진 첨부)
X.509 v3 인증서
일단 pass
서버 인증을 위한 인증서 사용하기
-HTTPS로 접속할 때 브라우저는 자동으로 접속한 서버에서 디지털 인증서를 가져온다.
-서버에 인증서가 없다면 보안 커넥션은 실패한다.
-서버 인증서는 아래를 포함한 많은 필드를 가지고 있다.
1)웹 사이트의 이름과 호스트 명
2)웹 사이트의 공개키
3)서명 기관의 이름
4)서명 기관의 서명
브라우저가 인증서를 받으면, 서명 기관을 검사한다. 공공이 신뢰하는 서명기관이라면 브라우저는 그 공개키를 이미 알고 있을 것이다(브라우저가 출시될 때 여러 서명 기관의 인증서가 미리 설치되어 있다).
(사진 첨부)
HTTPS의 세부 사항
-HTTPS별거 없다. 보안 전송 계층을 통해 전송되는 HTTP다.
-암호화 안된 HTTP메세지를 TCP로 보내기 전에 먼저 암호화하는 보안 계층으로 보낸다.
-HTTP =80포트, HTTPS = 443포트
보안 전송 셋업
HTTP: TCP 커넥션 열고-> request -> response ->커넥션 끊기
HTTPS는 좀 더 복잡한다.
TCP 연결 -> 암호법 매개변수와 교환 키를 협상하며 SSL 계층 초기화-> 핸드셰이크 완료 후 SSL초기화는 완료되며, 클라이언트는 request 보냄 ->request 메세지는 TCP로 보내지기 전 암호화 됨
(사진 첨부)
SSL 핸드셰이크
-프로토콜 버전 번호 교환
-양쪽이 알고 있는 암호 선택
-양쪽의 신원 인증
-채널 암호화하기 위한 임시 세션 키 생성
(사진 첨부)
사진은 SSL handshake의 단순화된 버전. 더 복잡해질 수도 있다.
서버 인증서
SSL은 server 인증서를 client에게, client인증서를 server에게 보내주는 상호 인증 지원.
하지만 client인증서는 잘 안쓰임.
반면, server 인증서는 항상 꼭 무조건 요구 된다.
서버 인증서는 X.509 v3에서 파생된 인증서다. 인증서 제대로 된건지 검증도 가능.
(사진 첨부)
사이트 인증서 검사
SSL자체는 사용자에게 웹 서버 인증서를 검증할 것을 요구하지 않지만, 최신 웹브라우저들 대부분은 인증서에 대해 간단하게 기본적인 검사를 하고 그 결과를 더 철저한 검사를 할 수 있는 방법과 함께 사용자에게 알려준다. 넷스케이프가 제안한 웹 서버 인증서 검사를 위한 한 알고리즘은 대부분의 웹브라우저의 검사 기법의 기초를 구축했다. 이 알고리즘의 수행 단계는 다음과 같다.
-날짜 검사
-서명자 신뢰도 검사
-서명 검사
-사이트 신원 검사
자세한 내용은 378P
가상 호스팅과 인증서
가상 호스트(하나의 서버에 여러 호스트명)다루는 건 까다롭다. 어떤 웹서버 프로그램은 오직 하나의 인증서만 지원하기도 한다.
-해서 redirect 사용.
(*.securiesites.com)
cajun-shop.securesites.com
cajun-shop.com
8. 진짜 HTTPS 클라이언트
SSL은 복잡한 binary protocol이다.
9. 프락시를 통한 보안 트래픽 터널링
client-server HTTPS통신 하려는데 중간에 프락시가 있다면?
server의 공개키로 암호화된 request를 보낸다면?
암호화된 request를 프락시가 읽을 수 없으니, 제대로 된 통신이 성공할 수 없다.
이를 가능하게 해주는 방법 중 가장 favorite한 방법이 터널링이다.
request보낼 때 프락시가 이해할 수 있게,
"야, 프락시야, 내가 지금 어떤 서버랑 통신하려고 하냐면~"
하면서 원서버의 정보ip:port를 평문으로 보낸다.
이게 CONNECT라는 메서드를 통해 이루어진다.
ip:port를 보내 연결이 성공하면, 데이터 직접 오갈 수 있게 터널을 뚫어버린다.
CONNECT메서드는 원 서버의 호스트:포트 뒤이어 스페이스 하나와 HTTP 버전 문자열과 CRLF가 순서대로 온다. 빈 줄도 온다. 여기까지 하고 만약 핸드셰이크가 성공했으면 SSL 데이터 전송이 시작된다.
예시
CONNECT home.netscape.com:443 HTTP/1.0
User-agent: Mozilla/1.1N
<SSL로 암호화된 데이터가 여기서부터 온다...>