HTTP’S’

HTTP의 단점과 HTTP’S’

• HTTP : 클라이언트가 서버에 민감한 정보를 요청 메세지에 실어보내야할 때 평문으로 데이터를 보냄, 설령 Base64와 같이 간단한 인코딩 방식으로 변환했다고 하더라도 인코딩 방법만 알면 금방 디코드 되기 쉬움
• HTTPS : 보안 개념이 더해진 HTTP(Secure Socker Layer) - SSL 프로토콜이 추가됨

인증된(안전한) 서버라는 것을 인증, 민감한 데이터를 암호화

• SSL(TLS) : 안전하게 데이터를 주고 받을 수 있게 해주는 프로토콜, HTTP 아래 계층(기반 프로토콜)
• 어떻게 ‘안전하게’?
  • 데이터 암호화 : 민감한 데이터를 평문으로 보내지않고, 암호화해서 보냄
  • SSL 인증서 : 클라이언트가 요청하려는 서버가 아무런 문제 없음을 인증함

데이터 암호화와 안전한 서버 인증

데이터 암호화 방식

• 대칭키 방식 : 암호화 하는 키와 복호화 하는 키가 같음, 한 쪽에서 암호화를해서 받은 쪽에서 복호화를 해야할 때 키를 전송해야하므로 중간 탈취 당하면 데이터가 그대로 누출됨(키와 데이터가 세트로 같이!)
• 공개키 방식 : 암호화 하는 키와 복호화 하는 키가 다름, 비밀키 - 공개키, 서버가 제공한 공개키로 클라이언트가 암호화해서 데이터를 전송하면 중간에 탈취되더라도 서버가 비밀키만 탈취 당하지 않으면 데이터 누출될 위험은 사라짐
  • 실제 서버 - 클라이언트 통신에서 공개키 방식을 사용하지않는다고 함, 복호화 과정이 대칭키 방식보다 훨씬 더 많은 파워가 소모되므로(성능상 단점), 서버 - 클라이언트 데이터 암호화를 위한 대칭키를 만들 때 공개키 방식을 사용함(대칭키 방식의 단점을 채우면서 성능도 챙겨가겠다는거지!)

/* private.pem(비밀키) 생성 */
> openssl genrsa -out private.pem 1024  # 1024는 복잡도
-----BEGIN RSA PRIVATE KEY-----
MIICXAIBAAKBgQCZLmrBl2uKEAnWiC+sBMMx1BRCggLz2lxjI+2wM153EPdgpV68
9flbv4I/R8
.
5Z2DBqDQJBAJ+R+B2xnrQWWimoelzUMWhp2r18l898lakWEFa0Zjc8
.
.
-----END RSA PRIVATE KEY-----


/* 비밀키를 통해 public.pem(공개키) 생성 */
> openssl rsa -in private.pem -out public.pem -outform PEM -pubout;
-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDl4pXg6GjvBjD3Z0efSZiC2fU3
M1oCCBOr3HAFtYxO2tlNnFTxU401p46ar41OdVU962fhL1GVgQay77QPDdQrNcBS
Ufu9nyY4vEx2B3F6wyJ1dYAts7W3U3tP+vKBQL2QjzDbPAGHtxKx21I76n52c4pb
WmZg9P42wpD4kDh1fwIDAQAB
-----END PUBLIC KEY-----


/* 공개키로 암호화 */
> openssl rsautl -encrypt -inkey public.pem -pubin -in data.txt -out data-encrypt.ssl
> cat data-encrypt.ssl
&Ao�m����u7��]�����`u��D�w�ɫ��*z�t����.�K����N`%\�ߚ�_�0�-z%=p���fw���T����i�
                                                                             :�[ł��\bg��K�6���|յ�z��oC%

/* 비밀키로 복호화 */
> openssl rsautl -decrypt -inkey private.pem -in data-encrypt.ssl -out data-decrypt.txt
> cat data-decrypt.txt
this is a plain text

안전한, 인증받은 서버 인증

• 공개키 방식 인증서 : 비밀키로 서버 정보(인증서)를 암호화한 후 클라이언트에 전송을 했을 때 공개키로 복호화가 된다면 서로 신뢰할 수 있는 상대 임을 인증할 수 있게됨, 데이터 보안에 있어서는 아무런 의미가 없어지지만 인증을 할 수 있게됨
  • 인증서를 주고 받는 것 자체는 암호화에 대한 개념이 없어도 되니깐 : 암호화 보다 인증의 용도로 키를 사용함
  • 서버가 전송해준 인증서가 제대로된 인증서인지 공개키로 복호화로, 인증서 정보(클라이언트 벤더가 인증한 기관에서 발급해주는 것이니깐)로 안전한 서버 임을 인증

HTTPS 지원 서버는 이렇게 동작한다

1. 인증서(+ 서버의 공개키) 전달 : 신뢰할 수 있는 서버인지 판단 - (1) 전달받은 인증서가 CA 목록에 있는지 (2) CA의 공개키(클라이언트에 내장)로 복호화 - 신뢰할 수 있는 인증 기관을 통해서 인증됨
2. 인증서 복호화가 되었다면 서버의 공개키 획득
3. 클라이언트 키 생성 후 인증서에 있던 서버의 공개키로 암호화 : 중간에 탈취되더라도 비밀키를 가지지 않았다면 복호화할 수 없음
4. 서버는 비밀키로 키를 복호화 : 서로 통신할 때 사용하는 대칭키 역할 - 대칭키를 안전하게 전달함으로써 대칭키 방식의 단점을 없애버림
5. 해당 대칭(세션)키(master secret)를 가지고 데이터를 주고 받음
6. 통신이 끝난 후 세션키는 폐기

직접 HTTPS 통신하기 : letsencrypt 사용

안되는 방법….

• localhost에서 개발 : nginx 설치(brew), hosts 파일 임시 수정(인증서 발급 설정할 때 도메인 무조건 필요 - 도메인 발급, DNS 등록하는 절차 생략을 위해서 호스트 파일만 수정)
  • 맥 호스트 파일 : /private/etc/hosts
  • certbot : 인증서 쉽게 발급할 수 있는 프로그램
• certbot에서 (임의로 정해둔) 도메인 주소로 가서 확인을 하는 관계로 에러발생 : 정식으로 호스팅하고 있는 도메인 주소여야 가능함

다시 꼭 해볼 것

• 다음에는 무료로 도메인 얻고 고정IP 발급받고(AWS) 연결해두는 것까지 한 상태로 다시 해보기
  • 무료 도메인

기타

• openssl : 여러 암호화 방식을 제공하고 데이터를 암호화 할 수 있는 프로그램(SSL을 구현한 오픈소스 프로그램), 키(비밀키, 공개키)를 생성할 수도 있음
• certbot : 인증서 발급을 쉽게 할 수 있음 무료로
• HTTP/2와 HTTPS : HTTP/2는 TLS 기반 동작 - 즉 HTTPS가 기본임, 성능 최적화와 더불어 보안에 신경을 썼기 때문

참고

• 생활코딩 - HTTPS와 SSL 인증서
• 초보몽키의 개발공부로그 - HTTPS와 SSL 인증서, SSL 동작방법
• 기억보단 기록을 - 스프링부트로 웹서비스 출시하기 시리즈 9
• certbot

세상에는 고수가 엄청 많다…!

RDMBS 인덱스 : mysql 기준

인덱스에 대해 알아보자

• 테이블의 특정 컬럼 데이터를 빠르게 찾기위해서 사용되는 자료구조 : 트리구조 - B-trees
• 특정 컬럼 범위 검색을 통해서 데이터의 위치를 찾음 : 테이블의 PK는 자동으로 인덱스 생성(기본 인덱스)
  • 데이터 저장은 페이지 단위로 : N페이지 M번째 위치 - 인덱스 leaf node(마지막 번째)에는 데이터의 위치가 있음
• PK 이외 컬럼을 인덱스 생성하면 leaf node에는 PK가 저장 -> PK로 인덱스에서 데이터 위치를 찾음 -> 데이터 가져옴
  • Secondary Index
• 풀스캔 하는 것보다 낫다! : 트리 구조로 되어있어서 범위 검색을 할 수 있는데 굳이 풀스캔한다면!

다음 할 것

• secondary 인덱스 지정 시 고려해야할 것 알아보기
• 인덱스 자료 더 찾아보기

참고

• mysql docs - how mysql uses indexes
• mysql docs - B-trees
• honux - mysql index