[ETC]인증서, 대칭키, 비대칭키

인증서

사설인증서
대상 컴퓨터에 액세스권한이 있는사람이 공급하며 내부망에서만 사용이 가능하다. 
비용부담이 없고 유지보수가 필요없으며 즉시 사용가능하다. 단, 클라이언트pc에 인증서를 수동으로 설치하여야 한다.

 

공인인증서
Thawte, Verisign과 같은 인증서 공급업체(CA)가 공급하며 인터넷에서 사용이 가능하다.
브라우저에서 인증서를 자동으로 인식하며 인증서사용자의 신원을 보장한다.

---

대칭키, 비대칭키

대칭키
암호화키 = 복호화키(암호화키와 복호화키가 대칭이다, 1개의 키 사용)
- 1개의 키를 사용하여 암/복호화가 빠름
- 키를 탈취당하면 암/복호화가 모두 이루어지므로 보안상 취약

따라서, 안전한 키교환방식이 요구됨
→ 키 배포 센터에 의한 해결, Diffle-Hellman 키 교환 방법에 의한 해결, 공개키 암호에 의한 해결.

대칭키 방식의 종류 : DES, 3DES, AES, RC4, SEED(국내개발), ARIA(국내개발)

 

cf. 키 교환방식에 대한 블로그글

https://mm89.tistory.com/entry/%EB%8C%80%EC%B9%AD%ED%82%A4%EC%99%80-%EA%B3%B5%EA%B0%9C%ED%82%A4-%EB%B9%84%EA%B5%90

대칭키와 공개키 비교

---

비대칭키(공개키)

암호화키 = 복호화키(개인키와 공개키 2개의 키 사용, 개인키로 암호화하면 공개키로 복호화해야하고 공개키로 암호화하면 개인키로 복호화해야 한다)
- 대칭키방식에 비해 속도가 느리다
비대칭키 방식의 종류 : RSA, DSA

방식1. 개인키로 암호화하는 경우
데이터를 자신의 개인키로 암호화한 후 전송하면 상대방은 암호화한 사람의 공개키가 있어야만 데이터를 열어볼 수 있다. 공개키는 누구나 알 수 있으므로 누구나 열어볼 수 있지만 이 방법은 데이터를 누가 보냈냐에 초점을 맞춘 방식이다(데이터제공자의 신원보장).
따라서, 인증서 발급기관, 공인인증서 등에 쓰임.

방식2. 공개키로 암호화하는 경우
데이터를 상대방의 공개키로 암호화한 후 전송하면 상대방은 자신의 개인키를 자신만 가지고 있기 때문에 자신의 개인키로 데이터를 안전하게 열어볼 수 있다.

---

HTTP, HTTPS

 

HTTP
- 인터넷에서 데이터를 주고받을 수 있는 프로토콜
- 기본 포트 : TCP 80번 ex)http://www.google.com:80(포트번호를 생략하면 기본포트를 사용하게 된다)
- TCP/IP를 기반으로 클라이언트의 요청을 서버가 응답하는 형식으로 동작
- 일반적으로 텍스트로 이루어진 HTML을 주고받는데에 사용됨.

 

HTTPS
- HTTP에 보안이 추가된 것. HTTPS는 SSL(TLS) 프로토콜을 통해 세션 데이터를 암호화하며, 대칭키방식과 비대칭키방식을 둘 다 사용한다.
- 기본 포트 : TCP 443
- SSL프로토콜 위에서 HTTPS프로토콜이 동작한다. SSL방식을 적용하려면 인증서를 발급받아 서버에 적용시켜야 한다. 인증서는 사용자가 접속한 서버가 우리가 의도한 서버가 맞는지를 보장하는 역할을 하는데 인증서를 발급하는 기관을 CA(Certificate Authority)라고 부른다. 웹 브라우저는 미리 CA리스트와 함께 각 CA의 공개키를 알고 있다.
HTTPS는 웹사이트의 무결성을 보호해준다. 인증서는 신뢰할 수 있는 CA에서 발급받아야 안전하다.

*SSL : 데이터를 안전하게 전송하기 위한 인터넷 암호화 통신 프로토콜
**TLS : SSL이후에 이것을 표준화하여 만들어진것

HTTP 참고 사이트

• https://www.zerocho.com/category/HTTP/post/5b344f3af94472001b17f2da
• https://surprisecomputer.tistory.com/54
• https://velog.io/@surim014/HTTP%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80#http-hypertext-transfer-protocol

HTTPS 참고 사이트

• https://rachel-kwak.github.io/2021/03/08/HTTPS.html

---

HTTP/0.9(One-Line Protocol)

- header가 없는 상태로 HTML만 전송
- 요청상태나 오류코드 알 수 없음

HTTP/1.0

- 응답에 status cod를 추가하여 브라우저가 요청에 대한 성공과 실패를 구별
- 요청과 응답에 헤더개념을 추가하여 메타데이터전송을 허용하고 유연성 및 확장성을 갖게함
- Content-Type을 명시하면서 다른 타입의 문서전달 가능(text, gif 등)

HTTP/1.1

- 커넥션의 재사용을 가능케해 Keep-Alive header를 통해 기존 연결과의 handshake 생략가능
- Pipelining 추가로 이전 요청의 응답을 완전히 전송되기 전에 다음 요청을 가능하게 해서 통신 대기 시간을 낮춤
- 청크된 응답을 지원
- 추가적인 캐시제어 메커니즘 도입
- Language, Encoding, Type 등을 포함한 컨텐츠 전송 
- Header 의 "Host" Field 동일한 IP 주소에 다른 도메인을 호스트하는 기능이 가능해짐

- Connection 한 개당 하나의 요청을 처리하도록 설계됨, 따라서 여러개의 요청을 받는 경우 앞선 요청에 대한 응답이 길어지면 그 이후의 응답들은 지연됨. (Head Of Line Blocking)
- HTTP의 특성상 3-Way Handshake가 반복적으로 일어나며, 불필요한 *RTT증가와 네트워크 지연을 초래하여 성능을 지연시킴
- 사용자가 방문한 웹페이지는 다수의 http요청이 발생하게 되는데, 이 경우 매 요청시 마다 중복된 헤더값을 전송하게 되고 해당 domain에 설정된 cookie 정보도 매 요청시 마다 헤더에 포함되어 전송되어 성능을 저하시킴
*RTT : 요청(SYN)을 보낼 때부터 요청에 대한 응답(SYN+ACK)을 받을 때까지의 왕복 시간을 의미

HTTPS

- 웹에서 주소록이나 이메일, 사용자의 위치 정보나 개인정보 등에 접근하면서 점점 보안의 중요성이 대두
- SSL은 TLS로 발전. 현재는 SSL이 아닌 TLS을 사용하지만, 보편적으로 SSL이라고 부르기 때문에 SSL/TLS을 혼용하여 부름.

SPDY

- 구글은 전송지연문제를 해결하기 위해 HTTP를 고속화한 새로운 프로토콜인 SPDY를 구현함
- HTTP/1.1에 비해 상당한 성능 향상과 효율성을 보여줬고 이는 HTTP/2 초안의 참고 규격이 됨
- 항상 TLS 위에서 동작 :  HTTPS로 작성된 웹 사이트만 적용 가능
-  HTTP 헤더 압축 : 요청이 많아질 수록 압축률은 커지고, 대역폭이 작은 모바일 환경에서 효과가 크게 보임
- 텍스트가 아닌 바이너리 프로토콜 : 파싱이 더 빠르고, 오류 발생 가능성이 낮음
- Multiplexing : 하나의 커넥션 안에서 다수의 독립적인 스트림을 동시에 처리
- Full-duplex interleaving & Prioritization : 다른 스트림이 끼어드는(interleaving) 것을 허용
- Server Push

HTTP/2

Multiplexed Streams : 하나의 TCP 연결을 통해 여러 데이터 요청을 병렬로 전송할 수 있다.
RTT시간 감소, 로드속도 빨라짐

- Header Compression : 중복 헤더 프레임을 압축해서 전송

- Binary protocol :  데이터의 파싱이 더 빠르고, 오류 발생 가능성이 낮음, 네트워크 리소스의 효과적 사용, 텍스트프로토콜에서 바이너리 프로토콜로 변화하여 텍스트 특성과 관련된 보안 문제를 해결할 수 있음, HTTP/2의 다른 기능(압축, 멀티플렉싱, 우선 순위 지정, 흐름 제어 및 TLS의 효과적인 처리 등)을 활성화 

- Server Push : 서버는 요청되지 않았지만 향후 요청에서 예상되는 추가 정보를 클라이언트에 전송할 수 있다.

- Stream Prioritization : 클라이언트가 선호하는 응답 수신 방식을 지정해서 응답을 받을 수 있다. 

 

참고 사이트 : https://gngsn.tistory.com/99

HTTP/2, 제대로 이해하기