14.1 HTTP를 안전하게 만들기
필요한 보안 기술
- 서버 인증
- 클라는 자기거 진짜 서버와 이야기할 수 있음을 보장받아야됨
- 클라 인증
- 무결성
- 클라와 서버는 그들의 데이터가 위조되는 것으로부터 안전해야한다
- 암호화
- 효율
- 보안이 적용되도 충분히 빨라야 한다.
- 편재성(Ubiquity)
- 프로토콜은 거의 모든 클라와 서버에 지원되야 한다.
- 관리자 확장성
- 적응성
- 사회적 생존성
14.1.1 HTTPS
- HTTPS 는 넷스케이프에서 창조
- HTTPS는 요청과 응답 데이터가 네트워크로 보내기 전 암호화됨
- HTTPS는 HTTP 하부에 전송 레벨 암호 보안 계층 제공함으로써 동작
- 이 보안 계층은 안전 소켓 계층(Secure Socket Layer, SSL) 혹은 그걸 계승한 전송 계층 보안(Transport Layer Security, TLS)를 이용하여 구현된다.
- SSL, TLS는 비슷해서 여기선 그냥 SSL 로 통칭한다.
- SSL, TLS는 비슷해서 여기선 그냥 SSL 로 통칭한다.
14.2 디지털 암호학
- 대칭키 암호 체계
- 인코딩과 디코딩에서 같은 키 사용
- 비대칭키 암호 체계
- 인코딩과 디코딩에서 다른 키 사용
- 디지털 서명
- 메시지가 위조 변조 되지 않았음 입증하는 체크섬
- 디지털 인증서
- 신뢰할만한 조직에 의해 서명되고 검증된 신원 확인 정보
14.3 대칭키 암호법
DES, Triple-DES, RC2, RC4
단점 중 하나는 발송자, 수신자가 서로 대화하려면 둘 다 공유키를 가져야한다는 것. 통신전 미리 둘만을 위한 키를 만들고 이를 공유해야된다. 그리고 그걸 어떻게 기억할지 정해야한다. 고객마다 키가 필요.
단점
- 주체들간 공유키 상호 보유 필수
- 통신 전 둘만을 위한 키 생성 및 공유 필수
14.4 공개키 암호법
두 개의 비대칭 키 사용. 하나는 인코딩, 하나는 디코딩용. 인코딩 키는 모두를 위해 공개되있다.
모든 사람이 X에 보내는 매시지를 같은 키로 인코딩이 가능하지 만, X를 제외한 그 누구도 그 메시지를 디코딩할 수 없다. 서버의 공개키만 있으면 손쉽게 암호화가됨.
14.4.1 RSA
공개키 방식의 핵심은, 설혹 아래 내용을 해커가 알더라도 비밀인 개인키를 계산못한다는 확신을 주는 것.
- 공개키(누구나 얻는다)
- 가로채서 얻은 암호문 일부(네트웍 스누핑해서 획득)
- 메시지와 그것을 암호화한 암호문(인코더에 임의의 텍스트를 넣고 실행하여 획득) RSA가 이를 충족하는 알고리즘 중 하나.
14.4.2 혼성 암호 체계와 세션 키
개인 키 협상이 붎필요, 하지만 알고리즘 계산이 느린 경향 존재. 실제로는 대칭과 비대칭을 섞는 방식 많이 쓰임. 예를 들어, 노드 사이 안전한 의사소통 채널 수립할 때는 편리하게 공개 키 쓰고, 이렇게 만들어진 안전한 채널 통해 임시 무작위 대칭 키 생성 및 교환하여 이후 나머지를 암호화 할 때는 빠른 대칭키를 사용하는 방식
14.5 디지털 서명
암호 체계는 메시지를 암호화하고 해독하는것 뿐 아니라 누가 메시지 썻는지 알려주고 그 메시지가 위조되지 않았음을 증명위해 메시지에 서명을 하도록 하는데 이용될 수 있다. 이 기술은 인터넷 보안 인증서에 중요하다.
14.5.1 서명은 암호 체크섬이다
디지털 서명은 메시지에 붙어있는 특별한 암호 체크섬. 다음과 같은 이점이 존재.
- 서명은 메시지 작성자를 알려준다
- 저자는 본인의 개인 키 갖고 있기에 오직 저자만이 이 체크섬 계산이 가능하다. 체크섬은 저자의 개인 ‘서명’처럼 동작한다.
- 서명은 메시지 위조를 방지한다
- 악의적 공격자가 송신 중인 메시지를 수정했다면, 체크섬은 더 이상 그 메시지와 맞지 않게될 것.
- 체크섬은 저자 비밀 키와 연관되있어서 침입자는 위조된 메시지의 올바른 체크섬 날조가 불가함 디지털 서명은 보통 비대칭 공개키에 의해 생성.
위 그림은 A→B메시지 보내며 서명하는 과정
- A는 가변 길이 메시지 정제하여 고정된 길이의 **요약(digest)**로 만든다.
- A는 그 요약에 개인 키를 매개변수로하는 ‘서명’함수를 적용. 이 서명덕에 개인 키를 가진 서명자가 소유자임을 보여줌
- 한번 서명이 계산되면, A는 그걸 메시지 끝에 붙이고 메시지와 서명을 B에게 보낸다.
- 메시지를 받은 B가 만약 메시지를 쓴게 정말로 A이고 동시에 위조되지 않았다느걸 확인하고 싶다면, B는 서명을 검사할 수 있다. B는 서명에 공개키를 이용한 역함수를 적용한다. 만약 풀어낸 요약이 B가 갖고있는 버전의 요약과 일치하지 않는다면, 위조되거나 발송자가 A의 개인 키를 갖고있지 않은것!(따라서 메시지를 쓴 것은 노드 A 가 아니다)
14.6 디지털 인증서
- 디지털 인증서 흔히 cert 라 불림
- 신뢰할 수 있는 기관으로부터 보증받은 사용자나 회사에관한 정보 담고있다
14.6.1 인증서 내부
- 대상의 이름(사람, 서버, 조직 등)
- 유효 기간
- 인증서 발급자(누가 이 인증서를 보장하나?)
- 인즌서 발급자의 디지털 서명 디지털 인증서는 대상과 사용된 서명 알고리즘에대한 정보 + 대상의 공개키도 담음. 누구나 디지털 인증서 만들 수 있지만, 그 모두가 인즌서의 정보를 보증하고 인증서를 개인키로 서명할 수 있는 널리 인정받는 서명 권한 얻을 수 있는건 아님
14.6.2 X.509 v3 인증서
- 디지털 인증서 표준은 없다
- 그럼에도 대부분의 인증서가 X.509라 부리는 표준화된 서식에 저장하고있다
- X.509 기반 인증서에는 웹 서버 인증서, 클라이언트 이메일 인증서, 솦웨어 코드사인 인증서, 인증기관 인증서 비롯한 몇가지 변종 존재.
14.6.3 서버 인증을 위해 인증서 사용하기
사용자가 HTTPS 통한 안전한 웹 트랜잭션 시작할 때, 최신 브라우저는 자동으로 접속한 서버에서 디지털 인증서를 가져온다. 서버가 인증서 없다면 보안 커넥션은 실패한다.
서버 인증서는 다음을 포함해 많은 필드 가짐
- 웹 사이트 이름과 호스트명
- 웹 사이트 공개키
- 서명 기관 이름
- 서명 기관 서명
브라우저가 인증서 받으면 발급(서명) 기관이 신뢰할만한지 체크한다. 이미 브라우저에 그 정보가 저장되있음. 그렇다면 공개키도 저장되어있음.
다음그림은 인증서의 디지털 서명 이용해 어떻게 그 인증서의 무결성 검증하는지 보여줌
14.7 HTTPS의 세부사항
14.7.1 HTTPS 개요
HTTPS는 보안 전송 계층 통해 전송되는 HTTP일 뿐.
14.7.2 HTTPS 스킴
HTTPS는 443이 기본 포트
SSL 트래픽은 바이너리 프로토콜이라서 HTTP와 완전히 다르다. 만약 SSL 트래픽이 80에 도착한다면 대부분 브라우저는 잘못된 HTTP로 해석하고 커넥션을 닫을 것임.
14.7.3 보안 전송 셋업
[HTTPS에서]
- 클라는 먼저 443 포트로 연결
- 일단 TCP연결되면, 클라와 서버는 암호법 매개변수와 교환 키를 협상하면서 SSL (계층)을 초기화
- 핸드셰이크 완료되면 SSL 초기화 완료
- 메시지는 TCP 보내기전에 암호화 된다.
14.7.4 SSL 핸드셰이크
암호화된 HTTPS 보내기전에 당연히 핸드셰이크가 필요하다. 이것도 TCP 기반임 결국은.
일어나는 일은
- 프로토콜 버전 번호 교환
- 양쪽이 알고 있는 암호 선택
- 양쪽의 신원 인증
- 채널을 암호화 하기 위한 임시 세션 키 생성
14.7.5 서버 인증서
SSL은 서버 인증서를 클라로 주고 다시 클라 인증서를 서버로 날려주는 상호 인증을 지원. 그러나 이 클라 인증서은 현대 웹브라우징에서는 안쓰인다.(그럼 왜 설명함;)
HTTPS 트랜잭션은 항상 서버 인증서를 요구한다. 서버 인증서는 조직의 이름, 주소, 서버 DNS 도메인 이름, 그외 정보를 보여주는 X.509 v3에서 파생된 인증서다. 사용자와 사용자 클라는 이 인증서가 믿을만한지 확인위해 인증서를 검증할 수 있다.
14.7.6 사이트 인증서 검사
브라우저가 하는 일 소개
날짜 검사
브라우저는 인증서 유효함 확인라혀 시작 및 종료일 확인함.
서명자 신뢰도 검사
모든 인증서는 서버를 보증하는 어떤 인증 기관(Certificated Authority, CA)에 의해 서명되있다. 누구나 인증서 생성은 가능하지만 몇몇 CA 는 인증서 지원자의 신원, 사업 선량함을 입증하는 신뢰할만한 잘 알려진 기관. 그래서 브라우저는 이 CA 목록을 포함해서 유저에게 배포된다. 잘 알려진 CA에서 파생된 자식 인증서도 브라우저는 받아들임
서명 검사
한번 서명 기관이 믿을만 하다 판단되면, 브라우저는 서명기관의 공개키를 서명에 적용해서 체크섬과 비교해봄으로써 인증서의 무결성 검사한다.
사이트 신원 검사
서버가 다른이의 인증서 복사나 트래픽 가로채기를 방지위해 대부분 브라우저는 인증서의 도메인 이름이 대화중인 서버의 도메인 이름과 맞는지 검사한다. 서버 인증서에는 보통 단일 도메인 이름이 있지만 몇몇 CA 는 서버 클러스터나 서버 팜을 위해 서버 이름의 목록이나 서버 이름들에대한 와일드카드 표현이 들어간 인증서를 만든다. 이게 틀리면 클라는 커넥션끊고 경고를 날릴것임
14.7.7 가상 호스팅과 인증서
가상 호스트(하나의 서버에 여러 호스트 명)으로 운영되는 사이트의 보안 트래픽 다루는건 까다로운 경우 많다. 몇몇 인기잇는 웹 서버 프로그램은 오직 하나의 인증서만지원함.
도메인 갑이 있다. 갑 사이트의 호스팅 제공자는 공식이름 을을 제공. 사용자가 갑에 접속시 서버 인증서에 나열된 공식 호스트 명 *.을 은 사용자가 브라우징했는 가상 호스트명 갑과 맞지않음. 이런 문제 피하려고 갑의 소유자는 보안 트잭하는 사용자를 을로 리다이렉트함
14.8 진짜 HTTPS 클라이언트
14.8.1 OpenSSL
SSL, TLS의 가장 인기있는 오픈 소스.
14.9 프락시를 통한 보안 트래픽 터널링
ok 읽음