HTTPS

김성수·2022년 11월 17일
0

SEB_BE

목록 보기
10/31

HTTPS

암호화

대칭키

  • 양쪽이 공통의 비밀 키를 공유하여 데이터를 암호화 및 복호화하는 것
  • 서버와 클라이언트가 데이터를 주고받을 떄 주로 사용하는 방법
  • 비대칭키 알고리즘보다 덜 복잡하다.

비대칭키

  • 각각 공개키와 비밀키를 가지고 상대가 나의 공개키로 암호화한 데이터를 개인(나)이 가진 비밀키로 복호화하는 것
  • 대칭키 알고리즘보다 훨씬 복잡하다.
  • HTTPS에서 사용하는 암호화 방법.
    • 중간에 대칭키가 탈취되더라도 개인키가 없이는 복호화할 수 없기 때문에 HTTPS에선 비대칭키를 사용한다.

인증서

  • CA
    • 인증서를 발급해주는 엄격하게 공인된 기관
    • Certificate Authority, CA라고 부른다.
    • CA들은 서버의 공개키와 정보를 CA의 비밀키로 암호화하여 인증서를 발급해준다.

Hashing

  • 모든 값에 대해 해시 값을 계산하는데 오래걸리지 않아야 한다.
  • 최대한 해시 값을 피해야 하며, 모든 값은 고유한 해시값을 가진다.
  • 아주 작은 단위의 변경이라도 완전히 다른 해시 값을 가져야 한다.
  • 대표적인 해시 알고리즘
    • SHA1, 요즘엔 SHA256을 많이 사용함. 차이는 너무 복잡s기때문에, 그런게 있구나 정도로만 이해하면 된

Salt(≠소금)

  • Salt는 소금, 보통 음식에 첨가하는 재료처럼, Salt역시 기존의 hash암호화해야 하는 값 에 어떤 별도의 값을 추가하여 결과를 변형한다는 의미이다.
  • 암호화만 해놓는다면 해시가 결과가 늘 동일하여, 해시된 값과 원래 값을 테이블로 만들어서 decoding 해버리는 경우도 생긴다.
  • 원본값에 임의로 약속된 별도의 문자열을 추가하여 해시를 진행한다면 기존해시값과 전혀 다른 해시값이 반환되어 알고리즘이 노출 되더라도 원본값을 보호할 수 있도록 하는 안전장치
    • 기존 : (암호화 하려는 값) => (hash 값)
    • Salt 사용 : (암호화 하려는 값)+(Salt용 값) => (hash 값)
  • 주의 사항
    • Salt는 유저 패스워드 별로 유일한 값을 가져야 한다.
    • 사용자 계정을 사용할 때와 비밀번호를 변경할 때마다 새로운 임의의 Salt를 사용해서 해싱해야 한다.
    • Salt는 절대 재사용하지 말아야 한다.
    • Salt는 DB의 유저 테이블에 같이 저장되어야 한다.


Cookie칙촉 먹고 싶음..

Cookie의 옵션

  • Domain

    • 쿠키의 옵션에 도메인 정보가 존재하면, 클라이언트에서는 쿠키의 도메인 옵션과 서버의 도메인이 일치해야만 쿠키를 전송할 수 있다.
  • Path

    • Path 옵션의 Path를 만족하는 Path가 존재할 때 서버에 쿠키를 전송할 수 있다.
    • 예시로 path가 /ssangsoo로 설정되어있으면, 세부경로가 /ssangsoo/pub으로 되어있는 경우라도 쿠키 전송이 가능
    • 반대로, path가 /ssangsoo로 설정되어있는데, /babo/pub으로 되어있으면, /ssangsoo를 만족하지 못해서 쿠키를 전송할 수 없다.
      • ㅋㅋ Path번역 : /쌩수, /쌩수/풉 /바보/풉
  • MaxAge or Expires
    *쿠키의 유효시간을 뜻한다.

    • MaxAge는 단순히 초를, Expires는 Date(날짜)를 지정한다. 클라이언트마다 지구 반대편에 있는지, GMT가 +3인 곳인지, +9인 곳인지, 절대시간은 지구위치마다 다르기 때문에 같이 적어주기도 한다.
      • 세션 쿠키
        • MaxAge 또는 Expires 옵션이 없는 쿠키로, 브라우저가 실행 중일 때 사용할 수 있는 임시 쿠키이다. 브라우저를 종료하면 해당 쿠키는 삭제된다.
      • 영속성 쿠키
        • 브라우저의 종료 여부와 상관없이 MaxAge 또는 Expires에 지정된 유효시간만큼 사용가능한 쿠키이다.
  • Secure

    • 쿠키를 전송해야 할 때 사용하는 프로토콜에 따른 쿠키전송 여부를 결정한다.
    • 이 옵션이 true로 설정된 경우, HTTPS프로토콜을 이용하여 통신하는 경우에만 쿠키를 전송할 수 있다.
    • Secure 옵션이 없다면, 프로토콜에 상관없이 어디든지 쿠키를 전송할 수 있다.
  • HttpOnly

    • 자바스크립트에서 브라우저의 쿠키에 접근 여부를 결정한다.
    • 이 옵션이 true인 경우, 자바스크립트에서는 쿠키에 접근이 불가능하다.
    • Default값은 false이다. false인 경우 자바스크립트에서 쿠키에 접근이 가능하므로, XSS 공격에 취약하다.
  • SameSite

    • Cross-Origin 요청을 받은 경우 요청에서 사용한 메소드와 해당 옵션의 조합으로 서버의 쿠키 전송 여부를 결정하게 된다.
    • 사용 가능한 옵션은 다음과 같다.
      • Lax : Cross-Origin 요청이면 GET 메서드에 대해서만 쿠키를 전송할 수 있다.
      • Strict : Cross-Origin이 아닌 same-site인 경우에만 쿠키를 전송할 수 있다.
      • None : 항상 쿠키를 보내줄 수 있다. 다만 쿠키 옵션 중 Secure 옵션이 필요하다.
    • same-site는 요청을 보낸 Origin과 서버의 도메인, 프로토콜, 포트가 같은 경우를 말한다. 이 중 하나라도 다르다면 Cross-Origin으로 구분된다.

이런 옵션들을 지정한 다음 서버에서 클라이언트로 쿠키를 처음 전송하면 헤더에 Set-Cookie 라는 프로퍼티에 쿠키를 담아
쿠키를 전송하게 된다.
이후 클라이언트 혹은 서버에서 쿠키를 전송해야 한다면 클라이언트는 헤더에 Cookie라는 프로퍼티에 쿠키를 담아 서버 쿠키를 전송하게 된다.

Session

은 스프링의 정석으로 충분..s...


origin과 site

둘다 URL을 말하는데, 차이는 이와 같다.

origin

  • https://www.google.com
  • https://www.google.com:443

위의 두 URl이 같은 Orgin이고,

  • http://www.google.com
  • http://www.google.com:80

위의 두 URL이 같은 Origin이다.
그냥 URL이 서브 도메인(www)과 메인 도메인(google.com), 포트번호까지 아예 똑같은 것.


site

  • http://www.google.com
  • http://api.google.com

위의 두 URL이 같은 site이다. 서브도메인은 다를지라도(www,api) 메인도메인이 같은 것.

profile
쌩수 Git >> https://github.com/SsangSoo?tab=repositories

0개의 댓글