HTTPS는 HTTP의 보안이 강화된 버전이다.
HTTP는 웹브라우저(Clinet)와 서버(Server)간의 웹페이지 같은 자원을 주고 받을 때 쓰는 통신 규약이다.
HTTPS는 인터넷 상에서 정보를 암호화하는 SSL(Secure Socket Layer)프로토콜을 이용하여 웹브라우저(클라이언트)와 서버가 데이터를 주고 받는 통신 규약이다.
장점
- HTTP는 바이너리 데이터로 되어있는 것도 아니고 단순 텍스트를 주고 받기 때문에 누군가 네트워크에서 신호를 가로채어 본다면 내용이 노출된다.(이런 보안상의 문제를 해결해주는 프로토콜이 HTTPS다.)
- HTTPS 프로토콜을 사용하면 웹 사이트 사용자가 인터넷을 통해 신용카드번호, 은행정보 및 로그인 자격 증명과 같은 중요한 데이터를 안전하게 전송 할 수 있습니다.
<출처 : http://cryptocat.tistory.com/3 >
암호화, 복호화시킬 수 있는 서로 다른 키 2개가 존재하는데 이 두 개의 키는 서로 1번 키로 암호화하면 반드시 2번키로만 복호화할 수 있고 2번 키로 암호화하면 반드시 1번키로만 복호화할 수 있는 룰이 있는 것이다.
- 그 중에서 하나 키는 모두에게 공개하는 공개키(1번 키)로 만들어서 공개키 저장소에 등록해놓는다.
- 서버는 서버만 알 수 있는 개인키(2번 키)를 소유하고 있으면 된다.
- 그러면 1번키로 암호화된 http 요청, 즉 HTTPS 프로토콜을 사용한 요청이 온다면 서버는 개인키(2번 키)를 이용하여 1번키로 암호화된 문장을 해독하게 된다.
- 서버는 요청이 무엇인지 알게되고 요청에 맞는 응답을 다시 개인키(2번 키)로 암호화해서 요청한 클라이언트에게 보내주게 된다.
- 응답을 받은 클라이언트는 공개키(1번 키)를 이용해서 개인키(2번 키) 암호화된 HTTPS 응답을 해독하고 사용하는 시나리오다.
HTTPS를 지원하는 서버에 요청(Request)을 하려면 공개키가 필요하다는 것을 알 수 있다.그러면 그 공개키는 공개키 저장소에 있다는 것은 알겠는데 어떻게 공개키 저장소에서 가져올까?
추가적으로 공개키는 누구나 얻을 수 있고 공개키를 알면 서버가 주는 데이터(Response)는 알 수 있는데 보안상에 의미가 있을까?
보안상의 의미는 없다.대신 얻을 수 있는 이점은 해당 서버로부터 온 응답임을 확신할 수 있다. 왜? 공개키로 해독이 가능했으니까 반드시 해당 서버의 개인키로 암호화했다는 것을 보장하기 때문이다.
https://www.youtube.com/watch?v=0cfUVrQW_yg&list=PLCZ-8rvakaqbplQZAoUku8uuxUgbLQm-1
어떤 SSL(Secure Socket Layer)을 사용하느냐에 따라 달라진다.
아마존, cerbot 등
ex) 클라이언트에서 aws에서 제공해주는 acm 인증서(SSL)을 사용하면 서버 역시 acm을 발급 받아 사용하여야한다.
aws로 발급 받는 방법
aws사이트 -> ec2 -> 로드 밸런서 -> Application Load Balancer(HTTPS) ->
1. 이름을 입력한다.
2. vpc를 기본값이 디폴트로 들어가 있고 2번째 사진의 내 EC2의 가용영역과 동일한 내역을 클릭하고 로드 밸런서 장점이 서버를 여러 개 돌릴 수 있다.(보통 3개 정도를 많이 클릭하던데 이유는 확실히 모르겠다.)
3. 보안 그룹에 내 EC2를 보안 그룹과 동일한 내역을 입력한다.
4. http가 기본으로 하나 있고 https를 추가로 하나 더 열어준다.
태그를 입력한다.(태그를 생성해주어야한다.)
5. 인증서를 선택해준다.(만들어둔 인증서가 없을 경우 아래의 과정을 수행한다.)
- 새 ACM 인증서 요청을 누르면 아래페이지로 가 인증서 요청을 할 수 있다.
인증서 요청을 해놓고 호스팅영역 도메인을 구매한다.
-> Route 53에 들어가서 도메인 등록
-> ec2를 살 때 연결된 카드 등으로 결제가 되고 5 ~ 10분 정도 후에 입력한 이메일로 날아온 메일을 확인한다.
-> 15분 정도 지나면 도메인이 등록이 되고 Route 53의 왼쪽에 호스팅 영역에 들어가서 유형 NS 값/트래픽 라우팅 대상의 값과 등록된 도메인의 이름 서버 값이 동일한지 확인한다.
-> AMC 인증서 요청에서 이름을 등록한 도메인 이름을 입력한다.
-> 레코드 생성을 누른다.
-> Route 53에 레코드 이름에 유형이 CNAME인 레코드 이름과 인증서에 들어 갔을 때 CNAME 이름이 동일하게 나와야된다.
이렇게 하면 인증서가 발급됨으로 바뀐다.
로드 밸런스 생성이 끝났다!!!
이제 얼마 안 남았다.
하단의 리스너를 클릭한다.
HTTP:80을 체크하고 편집을 누른다.
Add action을 Redirect로 바꿔준다.(기존 80에 있던 태그를 지운다. 로드 밸런싱에서 HTTP에 태그를 입력하지 않으면 생성이 안 되어서 입력했던 태그다.)
포트에 이전에 있던 포트값을 입력해준다.(443)
Full URL을 누르고 Save changes를 누른다.
상태가 활성으로 바뀌고 DNS이름을 복사하여 다시 Route 53으로 가 레코드 생성을 해준다.
생성에서 별칭을 활성화하고 아래에 3가지를 입력해준다.
3번째에 DNS 이름을 입력한다.
상태에서 조금 기다리면 INSYNC로 변경된다.
cors 문제도 발생하기 때문에 그 부분도 설정을 해줘야된다.
WebConfig에 허용하는 주소에 프론트와 백엔드주소를 둘 다 입력해주어야한다.
소셜로그인을 할 경우 아래와 같이 redirect_uri 주소를 변경해주어야한다.
kakao developers에 들어가서 주소도 추가해주어야한다.
윈도우에서는 git bash, 맥에서는 터미널을 열어
1. 내 EC2에 접속을 하고(ssh -i 키패드 ubuntu@EC2주소)
2. 포트포워딩을 확인(sudo iptables -t nat -L --line-numbers)
3. 안 열려있으면 열어준다.(sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 8080)
4. 다시 확인을 한 번 해준다.
다 되면 주소 입력시 이런 메세지의 창이 뜬다.
AWS로 처리를 하면 로드 밸런서가 처리를 해주므로 NGINX를 안 써도 된다.
이렇게 되면 이제 서버단에서는 끝났고 프론트는 따로 해야된다...
적용하는데 너무 할 것도 많고 내용이 길어 제대로 정리된지도 모르겠다...
자료출처
https://jeong-pro.tistory.com/89
https://github.com/GreenStep99/Backend/issues/113
https://velog.io/@sloools/Spring-Boot
https://velog.io/@byjihye/ubuntu3
https://nerd-mix.tistory.com/35
