24.10.19 day81 SSL

SSL(Secure Sockets Layer)

SSL은 인터넷에서 데이터를 안전하게 주고받기 위한 암호화 프로토콜이며, 웹 브라우저와 웹 서버 간에 전송되는 데이터를 보호하여 도청, 위조, 변조 등의 공격으로부터 데이터를 안전하게 보호한다.

SSL은 90년대에 개발되어 현재 SSL 3.0까지 발전되었다. 최근의 SSL은 더 발전된 TLS(Transport Layer Security)로 대체되었지만, 여전히 SSL이라는 용어로 사용되고 있다.

SSL의 주요 기능

1. 데이터 암호화(Encryption)
   • SSL을 통해 전송되는 모든 데이터는 암호화되는데, 데이터가 인터넷을 통해 전송될 때, 중간에서 데이터를 가로채더라도 해독할 수 없기 때문에 전송되는 정보의 기밀성이 유지된다.
   • 예시로 사용자가 웹사이트에서 결제 정보를 입력하면, SSL을 통해 카드 정보가 암호화되어 서버로 전송된다.
2. 데이터 무결성(Integrity)
   • SSL은 데이터가 전송되는 동안 변경되거나 손상되지 않도록 보호하며 데이터가 손상되거나 변조되었는지 여부를 확인하기 위해 전송되는 데이터에 해시 값을 포함시켜 무결성을 유지한다.
   • 예시로 사용자가 보내는 정보가 전송 중에 공격자에 의해 변조되면, 수신자는 이 변조를 감지할 수 있다.
3. 인증(Authentication)
   • SSL은 클라이언트와 서버 간의 통신에서 서버가 신뢰할 수 있는지 확인하는 기능을 제공하며 이를 위해 서버는 SSL 인증서를 통해 자신의 신원을 증명한다.
   • 해당 인증서는 신뢰할 수 있는 인증 기관(CA, Certificate Authority)에 의해 발급된다.
   • 예시로 사용자가 은행 웹사이트에 접속할 때, SSL 인증서를 통해 해당 웹사이트가 실제 은행의 서버임을 증명할 수 있는 수단이 된다.

SSL의 작동 원리

SSL이 작동하는 방식은 대칭키 암호화와 비대칭키 암호화를 결합하여 데이터를 안전하게 주고받는다.

1. SSL 핸드셰이크
   • 클라이언트와 서버 간의 연결이 시작되면 SSL 핸드셰이크가 발생하며 이 단계에서 클라이언트와 서버는 서로를 인증하고, 사용할 암호화 방법을 조율한다.
2. 서버 인증 및 공개키 전송
   • 서버는 클라이언트에게 자신의 SSL 인증서를 보내고, 이 인증서에는 서버의 공개키가 포함된다. 이 때, 클라이언트는 이 인증서를 인증 기관을 통해 검증하여 신뢰할 수 있는 서버인지를 확인한다.
3. 대칭키 생성
   • 클라이언트는 임시 대칭키(세션 키)를 생성하고, 서버의 공개키로 암호화한 후 서버로 전송한다.
4. 데이터 전송:
   • 클라이언트와 서버는 생성한 대칭키를 사용하여 데이터를 암호화하고, 이를 통해 안전하게 데이터를 주고받는다.

SSL 인증서

SSL 인증서는 클라이언트와 서버 간의 안전한 통신을 보장하는 핵심 요소이며, 인증서는 인증 기관이 발급하며, 이 인증서를 통해 서버가 진짜 서버임을 확인할 수 있다.

 

SSL 인증서의 정보

• 서버의 도메인 이름
• 서버의 공개키
• 인증서 발급 기관(CA)의 이름
• 인증서의 만료일

SSL은 주로 HTTPS 프로토콜과 함께 사용되는데, HTTPS는 기존의 HTTP에 SSL을 추가하여 보안을 강화한 프로토콜로, 웹사이트와 브라우저 간의 모든 데이터를 암호화한다. HTTPS는 홈페이지의 url에 https://로 되어있다.

 

프론트엔드쪽에선 SSL은 웹 애플리케이션과 서버 간의 통신을 안전하게 유지하는 중요한 요소이며 웹 애플리케이션을 개발하고 배포할 때 SSL을 통해 통신을 암호화하면, 사용자가 입력하는 민감한 정보가 중간에서 도청되거나 변조되는 것을 방지할 수 있다.

또한, SSL을 사용하지 않으면 CORS 보안정책 문제가 발생할 수 있는데, 현재 수많은 API와 리소스들은 HTTPS에서만 접근을 허용하기 때문에 http에서 접근하는 요청은 차단된다. 그래서 정적인 사이트가 아닌 통신이 필요한 사이트일 경우 HTTPS로 개발하는게 좋다.

사용자의 관점에서는 HTTPS 사이트가 아닌 HTTP 사이트에 접근할 경우 보안 이슈로 경고 알림을 보여주게 된다.

회사 공고를 보며 회사 사이트를 방문하거나 검색을 통해 특정 사이트에 접근하려고 할 때 해당 경고 알림이 뜨며 보안이 안된 사이트니 주의하라고 뜨는데, 해당 알림이 뜰 경우 무해한 사이트임에도 들어가기가 꺼려지고 사용할 때 불편하게 만든다. 이러한 입장으로 HTTPS로 만드는 것이 좋다. 실제로 구글에서는 HTTP로 개발한 사이트일 경우 검색했을 때 우선적으로 보여주지 않게 한다. 해당 검색과 정확한 사이트일 경우 뜨겠지만 여러 사이트가 나올 경우 HTTPS가 우선시되어 HTTP사이트는 최하단으로 박히게 되는 것이다.

 

프론트엔드에서 SSL 적용 시 고려 사항

1. SSL 인증서 설치 및 관리
   • SSL을 적용하려면 서버에 SSL 인증서를 설치해야 하며, 프론트엔드 개발자는 배포된 웹사이트가 HTTPS를 통해 제공되는지 확인해야 한다.
   • 특히 클라우드 서비스나 호스팅 서비스를 사용할 경우, SSL 인증서가 자동으로 제공되기도 하지만, 수동으로 인증서를 설정해야 할 때도 있기 때문에 잘 확인해야 한다.
   • 그리고 인증서는 주기적으로 갱신되어야 하며, 만료된 인증서를 사용하면 사이트가 안전하지 않다는 경고가 표시될 수 있다.
2. 리소스의 안전한 로드
   • 프론트엔드에서 로드하는 외부 리소스(이미지, 스크립트, 스타일시트 등)도 반드시 HTTPS를 사용해야 한다. 만약 HTTP로 리소스를 불러오면, 브라우저에서 혼합 콘텐츠(Mixed Content)라는 경고가 나타나고, 일부 리소스는 차단될 수 있다.
   • 혼합 콘텐츠 문제를 방지하려면 모든 외부 리소스 경로를 HTTPS로 가져와야 하고 웹 페이지에 포함된 링크들도 HTTPS로 변환해야 한다. 그리고 리소스의 경로도 상대적인 경로를 사용하면 좋다.
3. API 요청의 보안 강화
   • 프론트엔드에서 서버로 데이터를 전송할 때, 특히 로그인, 회원가입, 결제 같은 민감한 데이터를 다룰 때 HTTPS를 사용하지 않으면 그 데이터가 노출될 위험이 있다.
   • 이를 방지하려면 모든 API 요청이 HTTPS를 통해 암호화된 상태로 전송되도록 설정해야 한다.

 

다만, HTTPS의 경우 백엔드의 역할이 크며, 프론트엔드는 서버에서 설치한 인증서를 올바르게 요청하도록 코드를 작성해야 한다.

그리고 애플리케이션을 배포할 때 프론트엔드 측에선 SSL을 자동으로 지원하는 호스팅 서비스를 선택하는 것이 중요한데, 주 배포 요소인 AWS에서는 S3과 CloudFront를 함께 사용하면 HTTPS를 지원하는 배포환경을 쉽게 구축할 수 있다고 한다.

AWS말고도 배포시 HTTPS를 기본으로 지원해주는 Vercel이나, 깃허브 페이지를 사용하는 것도 좋을 것 같다.

 

리액트에서 HTTPS로 실행하려면 package.json의 페이지 실행 코드에 "HTTPS=true" 를 작성해주면 된다. 

혹은 직접 세팅한 프로젝트일 경우 webpack.config에 서버의 인증서 값을 가져와야 한다고 하는데

devServer: {
  https: true,
  key: fs.readFileSync('/path/to/your/server.key'),
  cert: fs.readFileSync('/path/to/your/server.crt'),
  ca: fs.readFileSync('/path/to/your/ca.pem')
}

이 부분은 직접 해보질 않아서 자세히는 모르겠다. 이후에 학습할 때 한번 찾아봐야겠다.

그리고 클라이언트에서 서버가 HTTPS를 기본으로 사용할 수 있도록 HSTS(HTTP Strict Transport Security)라는 걸 설정할 수 있다.

HSTS는 클라이언트가 HTTP 요청을 보내는 대신에 자동으로 HTTPS로 전환하도록 전달한다.

이를 확인하려면 개발자 도구에서

 Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

이러한 헤더가 포함되어 있는지 확인할 필요가 있다.