7일

• Event Driven 방식으로 설계할 때의 Naming 고려사항
  • Event 이름은 보내는 측의 입장으로 정한다.
    • eg. ui:click, list:updated, connected
  • Global Event Bus인 경우 발행하는 주체를 명시 하는 편이 좀 더 편하다.
    • eg. ui:click, file-store:saved
  • Handler 이름은 어떤 동작을 하는지 나타내는 이름으로 한다.
    • eg. eventBus.on("submit-button:click", requestNewJob), eventBus.on("characher:updated", refreshStatPanel)

19일

Cert 기반 인증 방식 간단정리

나중에 다시 정리해야 겠지만 일단 간략하게 정리..

• TLS 연결는 여러가지 기능을 가지고 있다.
  • 종단간 암호화
  • Server의 무결성 확인
  • Client의 인증
• cert 발급을 위한 script는 0xC0DE의 cert 발급 make script 참조

기본 사항

• Cert는 반드시 쌍이다.
  • 공개키는 공개된 키이며 비밀키는 공개되지 않는 키이다.
  • 비밀키로 암호화를 하면 공개키로 풀수있으며 역도 성립한다.
  • 어떤 암호화된 데이터가 공개키로 풀린다는 것은 비밀키가 쓰였다는 증거가 된다
    • 이러한 특징으로 인해 데이터를 비밀키로 암호화 하는 것을 Signing이라고 부른다.
• 한 Cert로 다른 Cert를 signing 할수 있다.
  • 이는 한 Cert의 비밀키가 사용 되었다는 보장이다.
• 스스로 Signed 되는 경우에는 self-signed 라고 부른다.

암호화

wikipedia 나 namu wiki가 나보다 설명을 잘하므로 이를 참조.

Server의 무결성 확인

• Server는 TLS handshake시에 자신의 공개키(그리고 signing chain)을 client에세 전달한다.
• Client는 signing chain 중에 자신이 신뢰하는 CA pool에서 일치하는 cert가 있는지 검사한다.
  • 일반적으로 --ca-cert등의 옵션으로 넣는 CA cert는 이 CA Pool에 임시로 cert를 넣기 위해 있는 옵션이다.(self-signed의 경우)
  • 공신력있는 기관이 CA 인 경우에는 운영체제나 브라우저에 cert가 저장되어 있으므로 --ca 옵션이 요구되지 않는 것이다.(돈주고 산 Cert)
• Singing 되어 있다면 해당 Cert의 SAN,CN 정보를 본다.
  • 만약 접속하려는 Domain 이나 IP 주소가 해당 Cert의 SAN,CN list에 없다면 중간자 공격으로 취급하여 연결을 끊는다.
  • 개발도중에는 이 값을 정확하게 넣을수 없는 경우들이 있어서 일반적으로는 이 확인만 무효화 하는 옵션을 따로 제공한다.(--tls-verification=false 등..)

Cert를 활용한 Client 인증

• 모든 Client를 signing 해줄수 있는 Cert 를 발급한다(이를 clientCA cert라고 하자).
  • self-signed 여도 상관없다.
  • Server의 인증서의 CA와 같아도 되고 달라도 된다.
• Client는 Client의 Cert를 발급 받을때 위의 clientCA cert로 Signing 한다.
• client는 Server에게 데이터를 보낼때 자신의 비밀키로 암호화 하여 보내며 자신의 공개키 정보도 같이 보낸다.
• Server는 client의 공개키가 ClientCA로 Signing 되었는지(clientCA의 공개키로 복호화 되는지) 확인한다.
  • Signing 되었다면, 해당 Cert를 신뢰한다.
  • 보통 client용 CN 에는 사용자 이름(계정이름)이 들어 있는 경우가 많다.
• 따라서 Servers는 모든 Client의 공개키 목록을 가지고 있지 않아도된다.
  • 당연히 clientCA의 비밀키가 유출되면 사용자를 마구 만들수 있게 되므로, 잘 보관 해야 한다.