[nginx] https 설정시 프록시 - https 상호관계 및 정리

1. 먼저 https를 사용하는 이유 : 

 - http만 사용하면 그 사이트에 접속할 때 그 사이트가 CA로부터 검증된 사이트인지 모른다.

 - 보통의 사람들은 비슷한 아이디, 비밀번호를 여러 사이트에 공유하기 때문에 악의의 B 사이트가 원래의 A 사이트와 비슷하게 만들어서 도메인을 만들고 사용자가 A사이트인줄 알고 B사이트에 계정을 입력했을 때 그 유저의 또 다른 많은 계정이 털리는 것과 같은 결과를 초래한다.

 - 그래서 그 사이트가 정말 유저가 원하는 검증된 사이트임을 https가 알려주는 것이다.

 - 사이트 도용 뿐만 아니라 그 계정을 입력한 뒤 서버로 정보를 보낼 때 그 중간에 해커가 가로챌 염려가 있다.

 - https에서는 클라이언트(브라우저)와 웹서버 사이에 정보교류에서 그 데이터들을 암호화하기 때문에 그 정보가 유출되더라도 복호화를 하지 못하기 때문에 안전하게 정보를 교류할 수 있다.

 

 

• 기밀성 HTTPS는 인터넷과 같은 공공 매체에서 두 참여자 간의 통신을 보호한다. 예를 들어, HTTPS가 없다면 와이파이Wi-Fi액세스 포인트Access Point를 운영하는 사람은 액세스 포인트를 사용하는 사람이 온라인에서 무언가를 구입할 때 신용카드와 같은 개인정보를 볼 수도 있다.

• 무결성 HTTPS는 변조되지 않은 정보로 목적지에 도달하게 한다. 예를 들어, 와이파이가 웹사이트에 광고를 추가하거나, 대역폭을 절약하고자 이미지 품질을 저하시키거나, 읽는 기사의 내용을 변조할 수 있지만 HTTPS는 웹사이트를 변조할 수 없도록 한다.

• 인증 HTTPS를 통해 웹사이트의 진위 여부를 확인할 수 있다. 예를 들어, 와이파이 액세스 포인트을 운영하는 사람이 가짜 웹사이트를 브라우저에 보낼 수도 있다. HTTPS는example.com이라는 웹사이트가 실제로example.com인지 확인한다. 일부 인증서는yourbank.com이 YourBank.Inc라는 걸 알리기 위해 해당 웹사이트의 법적 신원을 검사하기도 한다.

---

2. https를 적용하기 전 상황 : 

 - 결제한 dns를 갖고있다.

 - 운영중인 웹서버를 갖고있다.(nginx)

 - 웹서버에 dns를 등록해 놓은 상황

 

server {
	listen 80 default_server;
	listen [::]:80 default_server;

	root /var/www/html;
    	server_name example.com www.example.com;
    	
    	location / {
    	ry_files $uri $uri/ =404;
    }
}

 

default_server는 뭐고, root는 뭐고, 또 server_name은 뭐고 또 location? 

머리가 터졌는데 이제 이해가 간다.

https를 적용하기 전에 저 각각을 꼭 이해할 필요가 있다.

 

- listen 80 default_server :

여러 도메인으로 이 IP에 접속할 수 있다. 기존에 내가 결제해놓은 dns에 다른 서브도메인을 추가하는데 CNAME으로가 아니라 A 레코드로 이 ip에 연결을 해놓을 수도 있고 아예 다른 도메인 호스트로 이 ip에 접속할 수 도 있는 것이다.

이 때 내가 정해놓은, 내가 어떤 도메인으로 이 ip로 접속할지를 당연히 정해놓을 것이다. 그렇다면 그 도메인을

server_name에 등록해놓는다.

해당 도메인 별로 서버블록(server{})을 각각 설정해주면 각각의 도메인별로 다른 서버 응답이나, 정적페이지(root /var/www/~~~)를 보여줄 수 있는 것이다. 이것이 프록시 설정이다

 

이 때 내가 server_name으로 등록하지 않은 도메인주소로 이 ip에 접속을 하면 어떻게 될까?

 

저 default_server는 접속하는 포트(여기서는 listen옆에 80이므로 80포트 : http로 접속하는 모든 도메인)마다 하나씩 갖고있는데 해당 포트로 접속하고 웹 서버 관리자가 따로 server_name으로 등록하지 않은 도메인으로 들어오는 접속들을 모두

저 listen 80 default_server 를 갖고있는 서버블록(server {})에게 보내버린다.

 

각 nginx가 운영되는 웹서버의 포트마다 default_server를 무조건 갖고있고 default_server가 정의되어있지 않은 포트는 각 포트를 갖고있는 서버블록들 중 가장 위에 있는 서버블록이 default_server로 자동 지정된다.

 

 

- root /var/www/html : 

해당 서버블록으로의 요청이 들어왔을 때, 정적페이지(html파일)를 보내준다.

 

- server_name : 

여러 도메인으로 해당 ip로 들어올 수 있는데 웹 서버 관리자는 어떤 도메인으로 들어오냐에 따라 다른 응답(리버스 프록시)을 보여줄 수 있다. 그 이정표를 정해놓는 곳이 바로 server_name이다. 웹서버 관리자가 따로 지정하지 않은 도메인으로 들어온 요청은 함께한 포트를 확인하고 해당 포트의 default_server를 갖고있는 서버블록으로 보낸다

 

- location / {} :

갑자기 다른 이야기, 프록시 이야기를 잠깐 할건데, 리버스 프록시를 크게 두가지로 사용하였다(이게 거의 모둔가? 암튼).

(1) ip가 이 웹서버로 설정되었는 여러 도메인들로 부터 이 웹서버에 요청할 때, ip는 같지만 도메인이 다른 각각 도메인별로 응답을 다르게 해줄 때,

(2) 여러 클라이언트들이 같은 도메인 요청을 한꺼번에 중복으로 요청했을 때 과부하가 걸릴것을 방지하기 위해서 같은 서버(node 서버 등)를 여러개 웹서버에 올려놓은 다음 각각의 똑같은 도메인, 도메인 url 요청을 그 같은 여러개의 서버에 적절히 나눠서 응답을 해주면서 과부하가 걸리는 것을 방지할 때 = 로드밸런싱할 때

 

이 때 이 location은 이 로드밸런싱을 할 때, 각각의 쌍둥이 서버들이 각각 다른 서버 포트(로컬포트)를 갖고있는데

upstream 블록과 함께 내부 포트를 여러개로 나누어 로드밸런싱을 할 때 사용되었다.

 

3. https가 적용되는 상황

 - https://certbot.eff.org/lets-encrypt/ubuntuxenial-nginx 를 그대로 자신의 nginx에 적용하면 되는데 

뭐가 달라지는 것인가.

 - 저 instruction을 따라하다보면

 

sudo certbot --nginx

 

를 입력하는 곳이 있다. 이를 입력하게 되면

 

내가 등록해놓았던 server_name의 목록을 확인시켜준다.

클라이언트가 요청하는 도메인과 해당 웹서버 관리자가 server_name에 등록한 도메인을 끈끈하게 묶어 위의 https를 사용하는 이유 중 무결성을 달성할 수 있는 것이다.

이 과정을 거치면 도메인 등록 사이트에서 해당 웹서버(ip)로 향하는 도메인레코드를 더 생성하더라도 웹서버의 server_name으로 등록해 놓지 않은 도메인들은 접속이 차단된다.

 

- 따라서 해당 웹서버로 향하는 설정을 해놓은 도메인들을 모두 server_name으로 등록을 해놓은 다음 certbot의 설정을 하면된다.

만약 웹서버 안의 server블록의 추가나 수정, server_name 수정이 이루어진 경우엔 

 

sudo certbot --nginx

 

만 한번 더 입력, 설정해주면 된다.

 

4. 이제 내가 등록한 도메인으로만 웹서버에 접속이 된다. 

 

 

 

-https를 사용하는 이유 출처

https://developers.google.com/web/fundamentals/security/encrypt-in-transit/why-https?hl=ko

https://webactually.com/2018/11/http%EC%97%90%EC%84%9C-https%EB%A1%9C-%EC%A0%84%ED%99%98%ED%95%98%EA%B8%B0-%EC%9C%84%ED%95%9C-%EC%99%84%EB%B2%BD-%EA%B0%80%EC%9D%B4%EB%93%9C/