- Today
- Total
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |
- useformstatus
- 리액트 알림
- styled-component
- react toast
- 사회복무요원 훈련소
- 훈련소
- 오라클클라우드
- 자바스크립트 순수함수
- 리액트 라이프사이클
- 비동기 병렬처리
- NextJS
- 공익 훈련소
- localStorage
- react life sycle
- 훈련소 후기
- next.js toast
- svgr
- The above error occurred in the
- 산업기능요원 훈련소
- no-use-before-define
- angular
- sessionStorage
- 오블완
- query param
- 자바스크립트
- useRouter
- 리액트
- react
- resolved to branch.
- server action
아 그거 뭐였지
[CS] HTTP와 HTTPS, SSL과 대칭키 비대칭키에 대해 알아보자. 본문
HTTP?
서로 다른 시스템들 사이에서 통신을 주고받게 하는 프로토콜
HTTP 단점
HTTP는 암호화하지않은 평문 데이터를 전송하기때문에 외부에서 정보를 훔쳐볼수가있다.
이러한 보안성의 단점을 극복하기위해 HTTPS 프로토콜을 사용하게된다.
추가로 검색 엔진 최적화에도 도움이 된다.
구글에서는 HTTPS를 사용하는 사이트에는 검색 순위에 잘 나타나게 보상을준다.
HTTPS
HTTPS는 HTTP에 SSL 프로토콜을 사용한 프로토콜이다.
SSL을 사용하여 서버와 사용자 사이에 안전하게 암호화된 연결을 만들 수 있게 도와주고
정보를 주고받을때 정보가 탈취되는것을 막을수있다.
SSL?
Secure Sockets Layer의 약자로
Netscape 인증사에서 개발한 웹 서버와 웹 브라우저간의 보안을 위해 만들어진 프로토콜이다.
공개키 방식과 대칭키 방식을 혼합하여 사용한다.
공개키 방식으로 대칭키를 전달한다. 대칭키를 활용해서 암호화와 복호화를 하고 서버와 클라이언트
간 통신을 진행한다.
대칭키?
- 송신하는쪽과 수신하는쪽이 동일한 키를 가지고 암호화 하고 복호화하는 방식
- 키를 가지고 있으면 누구나 암호화 복호화 할수있어 암호화 복호화 과정이 쉬움
한계점
양쪽이 키를 가지기위해서는 최소 한번은 키를 공유해야 하는데
이때 키를 도난당하게 되면 결국 정보를 훔쳐볼수있음
공개키? (비대칭키)
서로 다른 키로 암호화 복호화하는 방식
대칭키에서는 A라는 키로 암호화,복호화 전부 가능한데
공개키 방식에서는 A라는 키로 암호화를 하면 B라는 키로만 복호화가 된다.
공개키로 암호화하면 그 쌍이되는 개인키로만 복호화할수있고,
개인키로 암호화하면 그 쌍이되는 공개키로 복호화할수있다.
공개키는 노출되어도 상관없다.
한계점
공개키 방식보다 암호화 연산 시간이 더 소요되어 비용이 크다.
공개키 방식에서의 차이
공개키로 암호화 할때
- 데이터 보안에 중점
- 상대방의 공개키로 암호화 하고 데이터를 전달하면 데이터를 받은 사람은 개인키로 해당 데이터를 복호화
개인키로 암호화 할때
- 인증 과정에 중점
- 인증자는 자신의 개인키로 요청받은 사용자의 공개키를 암호화하고 사용자에게 전달 (인증서)
- 해당 인증서는 인증자의 공개키로만 복호화가 가능 (브라우저에 내장)
TLS?
SSL 암호화 프로토콜에서 발전된 방식
SSL은 2015년도에 공식적으로 사용종료되었음
TLS 1.3버전에서 보안과 속도적인 측면을 크게 향상시키고 현재는 SSL대신 TSL를 사용중임.
Netscape가 더이상 개발에 참여하지않고 IETF에서 업데이트를 하면서 이름이 변경됨
허나 SSL의 이름이 대중적이여서 현재까지도 SSL이라고 불리기도함
SSL 통신과정
인증서 발급과정
CA : Certificate Authority (인증기관)
- 서버는 CA에게 서버정보와 공개키를 전송한다.
- CA는 정보를 검증한뒤 서버공개키를 CA개인키로 서명한뒤 인증서를 만들어 서버로 전송한다.
2-1 인증서에는 서버정보와 서버의 공개키가 담겨있다. - CA는 사용자에게 공개키를 넘겨주는데 이 공개키는 브라우저에 기본적으로 내장되어있다.
이점을 참고하여 사용자와 서버가 통신하는 과정을 보도록하자
사용자는 서버를 신뢰할수없기에 SSL Handshake 과정을 거치게된다.
- 사용자가 서버로 랜덤 데이터를 전송한다.
- 서버에서는 답변으로 랜덤데이터와 서버인증서를 전송한다.
- 사용자는 브라우저에 내장된 CA 공개키로 서버의 인증서를 복호화한다.
3-1 서버의 인증서는 CA의 개인키로 암호화되어있기때문에 CA의 공개키로 복호화가 성공한다면 해당 인증서는 유효하다고 볼수있다. - 복호화에 성공하면 인증서에서 서버의 공개키를 얻게된다.
- 사용자는 서버와 사용자가 랜덤으로 생성한 데이터를 혼합해서 임시키를 만든다.
- 임시키를 서버의 공개키로 암호화해서 서버로전송한다.
6-1 (이렇게 하면 임시키를 안전하게 전달할수있음, 공개키를 복호화할수있는것은 개인키밖에없기때문) - 서버에서 전달받은 공개키를 서버 개인키로 복호화해서 임시키를 얻는다.
- 사용자와 서버는 이 임시키를 가지고 동일한 대칭키를 생성한다.
- 핸드셰이크가 완료되고 해당 대칭키를 사용하여 안전하게 통신을 하게된다.
9-1 공개키 방식으로 얻어낸 대칭키로 통신을 진행하게된다.