HTTPS, SSL Security


HTTPS, SSL


HTTPS = HTTP + Secure


기본 HTTP는 데이터 아이디 암호가 원본 텍스트 그대로 전달됨

Over Secure Socket Layer
SSL을 사용해 안전하게 한다.

SSL은 넷스케이프가 고안, 
표준과 기구인 IETF를 통해 TLS 이름이 됨. 
TLS 1.0 <= SSL 3.0을 계승함
그러나 TLS보다 SSL이라는 용어가 더 범용적. 
SSL/TLS => 그냥 SSL임

SSL 디지털 인증서

클라이언트, 서버간 통신을 보증해주는 제3자가 제공해주는 문서.
통신내용 노출 방지
서버가 접속하려는 서버가 맞는지, 중간에 가로채지는 않는지 확인

어떻게? => 암호화

선행적 암호화 방식 설명

암호화 방식에는 두가지가 있음

1. 대칭 방식 (Symmetric)

- encryption/decryption 2가지의 연산: openssl enc
- 단일 키를 가져 단순
- 키값 배달은 어떻게 할 것인가
. 키값노출에 따른 리스크가 매우 큼

DES암호는 대칭 암호체계

echo 'this is the plain text' > plaintext.txt;
openssl enc -e -des3 -salt -in plaintext.txt -out ciphertext.bin;

openssl enc -d -des3 -in ciphertext.bin -out plaintext2.txt;

2. 비대칭 방식, (Asymmetric, 공개키)

- encryption/decryption/sign/verify 4가지의 연산: openssl pkeyutl 또는 openssl rsautil 을 사용
- 개인키, 공개키 두가지가 있음
A키로 암호화를 하면 B키로만 복호화할 수 있고, B키로 암호화하면 A키로만 복호화할 수 있음
- 키값 배달은 할 필요가 없음
- 공개키로 암호화하고 개인키로 복호화하기 때문
- 개인키로 암호화하고 공개키로 복호화

"만약 암호화된 메시지가 공개키로 복호화할 수 있었다면 그 메시지는 개인키를 소유한 곳에서 만들었음이 보증됨"
-> 이 것이 인증서의 원리

RSA암호는 비대칭(공개키) 암호체계

openssl genrsa -out private.pem 1024;

openssl rsa -in private.pem -out public.pem -outform PEM -pubout;

echo 'coding everybody' > file.txt
openssl rsautl -encrypt -inkey public.pem -pubin -in file.txt -out file.ssl;

openssl rsautl -decrypt -inkey private.pem -in file.ssl -out decrypted.txt

SSL인증서

역할: 접속한 서버가 내가 접속하려한 서버가 맞는지 확인. 
중간 가로채기가 아닌지

클라이언트는 SSL통신에 사용될 공개키를 획득
 > 암호화하기 위함

CA (Certificate Authority): 

인증서를 통한 보안을 하지만 인증서 파일자체가 잘못된 것일 수도 있다. 인증서파일이 정상적임을 보증
웹브라우져 제작사 (애플, 마이크로소프트 등)가 지정함

VeriSign , Comodo, GoDaddy, GlobalSign과 같은 업체가 있음
인증서 구입비 필요, 무료도 있음
"'Free SSL Certificate'라고 구글, CloudFlare와 Let's Encrypt 확인"

http://en.wikipedia.org/wiki/Comparison_of_SSL_certificates_for_web_servers



담고 있는 내용:
1. 서비스의 정보( 인증서를 발급한 CA, 서비스의 도메인 등)
2. 서버측 공개키 (공개키의 내용, 공개키의 암호화 방법)

인증서 인증 과정
1. 클라이언트는 서버에 접속하면 공개키를 다운받음
2. 다운 받은 인증서의 인증기관이 사용중인 브라우져의 루트인증기관에 포함되어있다면 해당 인증기관에 대해 브라우져에 저장된 공개키를 통해 인증서로 복호화함.
- 복호화되지 않는다면 정상적인 인증서가 아니란 뜻이 됨.
- 또한 신뢰할 수 없는 사이트였으면 CA에서 발급하지 않았을 것이다

SSL작동방법

이론적 토대의 작동방식은 다음과 같을 것이다

클라이언트는 서버가 제공한 공개키로 암호화해 데이터전송
서버는 전송된 데이터는 자체로 가진 개인키로 복호화해 사용

그러나 컴퓨팅 파워를 감안해 다음과 같은 혼합방식 사용

실제데이터: 연산량이 적은 대칭키 사용 (DES), 
키값을 공유할 때만 비대칭키를 사용함

1. Hand-shake
1.1. 클라이언측에서 생성한 랜덤 데이터 서버로 전송, pre master secret
1.2. 클라이언트가 지원하는 암호화 방식을 협상 시도
1.3. 세션 아이디: 
1.4. 서버측에서 생성한 랜덤데이터 클라이언트로 전송
1.5. 서버가 선택한 암호화 방식을 클라이언트에 알려줌
1.6. 인증서 전송
1.7. 인증서 해석: 
- 클라이언트는 서버의 인증서가 CA에서 발급되었는지 확인, 
- 루트 인증기관 리스트에서 확인, 있으면 내장된 CA 공개키를 사용해 인증서 복호화, 
(복호화가 된다면 해당 CA에서 발급한 인증서임을 신뢰할 수 있게됨.)
- 클라이언트는 해당 서버와의 교신을 위한 공개키를 획득
1.8. 1.1. 에서 생성한 랜덤데이터를 인증서를 통한 공개키로 클라이언트에서 암호화해 서버로 전송
1.9. 서버는 전송된 암호데이터를 복호화해 세션 키값으로 사용

2. 전송
2.1. 세션키값을 사용해 대칭 형식 암호화 사용

3. 세션 종료
3.1. 세션키 폐기




덧글

댓글 입력 영역