[ TIL ] [ 정규과정 : 주특기프로젝트주차 ] HTTPS / HTTP

* 이번 주특기프로젝트에서 https로 배포해야 하는 부분이 있었다.

배포환경에 맞춰 설정을 하면서 알게 된 것과 추가로 공부한 것들을 오늘자 til에 기재해야겠다.

---

 

Https를 왜 써야할까?

HTTPS는 TLS 암호화를 갖춘 HTTP. HTTPS는 TLS(SSL)를 사용하여 일반 HTTP 요청과 응답을 암호화하므로 더 안전하고 보안이 강화됩니다. HTTPS를 사용하는 웹 사이트의 URL 앞에는 http:// 대신 https://(예: https://www.cloudflare.com)가 있다.

웹 사이트에서는 왜 HTTPS를 사용해야 할까? 

 

1) HTTPS를 사용하는 웹 사이트는 사용자가 더 신뢰할 수 있습니다.

HTTPS를 사용하는 웹 사이트는 지역 식품 안전 검사관으로부터 "합격"을 받았음을 게시하는 식당과 같다.

잠재 고객은 큰 부작용 없이 해당 업체를 이용할 수 있다는 것을 신뢰할 수 있다.

요즘 같은 시대에 HTTP를 사용하는 것은 식품 안전 검사 "불합격" 표시를 게시하는 것과 같다. 고객에게 뭔가 안 좋은 일이 발생하지 않는다는 보장이 없다.

HTTPS는 SSL/TLS 프로토콜을 사용하여 통신을 암호화하므로 공격자가 데이터를 탈취할 수 없다.

또한 SSL/TLS는 웹 사이트 서버가 실제 서버임을 확인하므로 사칭이 방지된다. 이는 식품 안전이 질병을 예방하는 것과 마찬가지로 여러 종류의 사이버 공격을 차단한다.

일부 사용자는 SSL/TLS의 이점을 인식하지 못할 수도 있지만, 최신 브라우저에서는 어떤 경우에도 웹 사이트의 신뢰성을 인식하도록 하고 있다.

 

▶︎ Chrome 등의 브라우저에서는 모든 HTTP 웹 사이트를 "안전하지 않음"으로 표시한다.
Google에서는 여러 해에 걸쳐 점진적으로 조치를 취하여 웹 사이트에 HTTPS를 도입하도록 했다.

Google 또한 검색 결과를 반환하는 방식에서 품질 요소로 HTTPS를 사용하며, 웹 사이트의 보안 수준이 높을수록 방문자가 Google이 제공한 링크를 클릭함으로써 실수할 가능성이 낮아진다.
2018년 7월 Chrome 68 출시와 함께 보호되지 않은 모든 HTTP 트래픽은 URL 표시줄에 '안전하지 않음'이라고 표시된다. 이 알림은 유효한 SSL 인증서가 없는 모든 웹 사이트에 표시된다. ( *다른 브라우저도 그 뒤를 따름 ) 

 

2) 사용자와 웹 사이트 소유자 모두에게 HTTPS가 더 안전하다.

HTTPS를 사용하면 원본 서버로 전송되는 데이터와 원본 서버에서 수신되는 데이터의 양방향 전송이 모두 암호화됩니다. 프로토콜은 악의적인 당사자가 전송되는 데이터를 관찰할 수 없도록 통신을 안전하게 유지한다. 따라서 사용자가 양식에 사용자 이름과 비밀번호를 입력할 때 이들 정보가 전송 중에 도난당하지 않는다. 웹 사이트나 웹 애플리케이션에서 사용자에게 중요한 데이터나 개인 데이터(예: 은행 계좌 정보)를 전송해야 하는 경우, 암호화를 통해 해당 데이터도 보호될 수 있다.

 

3)  HTTPS에서는 웹 사이트가 인증된다.

Uber나 Lyft와 같은 차량 공유 앱의 사용자는 운전자가 픽업하러 왔다고 말한다고 해서 낯선 차에 무작정 올라탈 필요가 없다. 대신 앱에 운전자의 이름과 외모, 운전하는 차량의 종류, 차량 번호 등 운전자에 대한 정보가 표시된다. 공유 차량이 모두 다르고 운전자를 한 번도 본 적이 없더라도 사용자는 이러한 사항을 확인해서 올바른 차량에 탑승하게 되는지 확인할 수 있다.
마찬가지로 사용자가 웹 사이트를 탐색할 때 실제로 하는 일은 한 번도 본 적 없는 사람이 관리하는, 잘 알지 못하고 먼 곳에 있는 컴퓨터에 연결하는 것이다. HTTPS를 활성화하는 SSL 인증서는 차량 공유 앱의 운전자 정보와 같다. 이는 신뢰할 수 있는 제삼자가 웹 서버가 자칭하는 실체임을 외부에서 검증하는 것을 의미한다.
이를 통해 공격자가 웹 사이트를 사칭하거나 스푸핑 하여 사용자가 실제로는 가짜 사이트에 접속하고 있는데도 의도한 사이트에 접속한 것처럼 보이게 하는 공격이 방지된다. 또한 HTTPS 인증은 회사 웹 사이트가 합법적으로 보이도록 하는 데 많은 도움을 주며, 이는 회사에 대한 사용자의 태도에도 영향을 준다.

 

HTTPS에 대하여 오해와 진실 

 

"웹 사이트에서 중요한 정보를 취급하지 않으므로 HTTPS가 필요하지 않다"

예를 들어, 일부 인터넷 서비스 공급자는 실제로 HTTP로 제공되는 웹 사이트에 광고를 삽입한다. 이러한 광고는 웹사이트의 콘텐츠와 방향이 일치하거나 일치하지 않을 수 있으며, 웹사이트 수익을 공유하지 않는다는 사실은 제쳐두더라도, 잠재적으로 공격적일 수 있다. 사이트의 보안이 확보되면 이러한 삽입 광고는 더 이상 실행할 수 없다.  최신 웹 브라우저에서는 이제 안전하지 않은 사이트에 대하여 기능을 제한합니다. 웹 사이트의 품질을 향상하는 중요한 기능에는 이제 HTTPS가 필요하다. 위치 정보, 푸시 알림, 프로그레시브 웹 애플리케이션(PWA)을 실행하는 데 필요한 Service Workers는 모두 강화된 보안을 필요로 한다.

 

"페이지 로드 시간을 늘려 웹 사이트의 성능을 저하시키고 싶지 않다"

시간이 지남에 따라 HTTPS가 개선되어 암호화된 연결을 설정하는 데 필요한 성능 오버헤드를 줄일 수 있게 되었다. 

TLS 세션 재개 및 TLS 잘못된 시작을 포함하여 연결 생성의 총 대기 시간을 줄이기 위해 TLS에 개선 사항이 구현되었다.
세션 재시작을 사용하면 서버가 추가 요청에 대해 동일한 세션을 다시 시작하여 연결을 더 오래 유지할 수 있습니다. 

연결을 유지하면 클라이언트가 캐시 되지 않은 원본 가져오기를 요구할 때 연결을 다시 협상하는 데 소요되는 시간이 절약되므로 총 RTT가 50% 감소했다.

 

"HTTPS를 구현하려면 비용이 너무 많이 든다"

이제는 더 이상 비용이 걱정되지 않습니다. Cloudflare에서는 웹 사이트에 무료로 전송을 암호화하는 기능을 제공합니다. 

 

출처 : https://www.cloudflare.com/ko-kr/learning/ssl/why-use-https/#

 

---

아래는,  프로젝트에서 https를 사용하기 위해 변경한 부분이다. 

https를 사용하는 경우, 쿠키를 안전하게 전송하고 보호하기 위해서 아래와 같은 설정이 필요하다. 

 

[기존코드]

// 사용자 로그인 API
res.cookie('Authorization', `Bearer${accessToken}`, {httpOnly: true});
res.cookie('refreshToken', refreshToken, {httpOnly: true});

//accessToken 재발급 API
res.cookie('newAccessToken', newAccessToken, {httpOnly: true});

문제점 : http에서만 사용될 수 있도록 설정되어 있어서 https 배포환경에서는 로그인이 되지 않는다.

( * 확인하는 방법 :  터미널에서 ubuntu로 접속해 있을 때, pm2 log 명령어로 확인)

 

[ 해결방법] 

httpOnly: true, 
sameSite: process.env.NODE_ENV === ‘production’ ? ‘none’: ‘lax’, // https 환경에서는 none으로 설정 
secure: process.env.NODE_ENV === ‘production’ //이 조건에 의해서 true 일 경우에 '쿠키는 HTTPS 연결을 사용하는 경우에만 브라우저로 전송한다.'

위 와 같은 설정을 추가로 해줘야 한다.

 

[변경된 코드]

// 사용자 로그인 API
res.cookie('Authorization', `Bearer ${accessToken}`, cookieOptions)
res.cookie('refreshToken', refreshToken, cookieOptions);

//accessToken 재발급 API
res.cookie('newAccessToken', newAccessToken, cookieOptions);

---

 

 

 

 

 

뭐 했는데

벌써 프로젝트 일주일 뚝딱 갔죠?

.....

이러다 눈 감았다 뜨면 항해 끝났겠네..