TLS cipher suite 읽는 법
작년부터 시작해서 보안 버그가 일종의 PR 결전장이 된 것 같은데 — 매우 핫한 이름을 붙여가면서 — 그런 류의 글에 나오는 TLS/SSL cipher suite 읽는 법을 간략히 정리.
TLS (혹은 옛이름(?)인 SSL) cipher suite은 아래와 같은 형태로 쓴다:
이전 글의 국민은행이 사용하던 RSA_WITH_AES_256_CBC_SHA 라거나, 현재 위키백과 설정인 ECDHE_ECDSA_WITH_AES_128_GCM, 이 블로그의 현재 설정 값인 ECDHE_RSA_WITH_AES_128_GCM 이라거나. 이 각각의 기능 구분은 아래와 같다
키 교환: 밑의 벌크 암호화 알고리즘에서 사용할 키를 교환할 방법 인증: 상대방이 정말로 스스로가 생각하는 상대방이 맞는지 확인할 방법 벌크 암호화: 대칭키를 써서 실제로 메시지를 암호화 하는 방법 메시지 인증: 이 메시지가 정말로 상대방이 보낸게 맞는지 확인할 방법 이렇게 4 부분으로 쪼개진다.
은행은 왜 이렇게 오래된 인증서 알고리즘 / 암호화 알고리즘을 쓰는 걸까
Disclaimer: 작성자 본인은 암호학 전문가가 아닙니다. 이글에선 무엇도 보장하지 않고 이글을 참고해서 하는 일에 대해선 어떤 책임도 지지 않습니다.
국민은행이 모던 브라우저에서 인터넷 뱅킹이 된다기에 시험 해 봄. 근데 들어가자마자 뜨는 워닝이 너무 우울해서 몇 가지를 확인.
인증서가 SHA1 해시를 이용 인증서가 유효한지 확인하기 위해서는 해당 인증서가 유효한지 확인하기 위해 인증서의 해시 값을 구하고, 이를 서명해둔다. 이 때 암호화 해시 함수; cryptographic hash function 을 이용하는데, 여기서는 SHA1 해시 함수를 쓰고 있더라.
카톡에서 쓰는 것으로 보이는 user-agent 가 눈에 띄기에
얼마 전부터 대략 이렇게 생긴 user-agent 가 웹 서버 접근 로그에 남는다:
*.*.*.* - - [07/Sep/2015:??:??:?? +0000] "GET /archives/3454 HTTP/1.1" 200 9925 "-" "facebookexternalhit/1.1;kakaotalk-scrap/1.0;" IP 주소에 대한 whois 정보 역시 Daum 소유의 것으로 나옴. Facebook 용으로 og:* metatag 류의 태그를 지정하는 경우 가 왕왕 있어서 그런 정보를 쉽게 가져가려고 facebook 외부 접근 에이전트 (facebookexternalhit/1.1) 호환이라고 내보내는 모양.
카카오 톡에 링크 공유하면 미리보기 띄우는 용도일듯? (Facebook 역시 그런 용도 + alpha 로 저걸 쓰는 듯 하니.
리뷰: 셜록 홈즈: 모리어티의 죽음 – 앤터니 호로비츠
둘째 태어나기 좀 전에 “셜록 홈즈: 실크하우스의 비밀"을 읽었던 것 같은데 그 후속이 나왔다. 이번에 다루는 부분은 “마지막 사건"과 “빈 집의 모험” 사이 이야기다. 즉, 라이헨바흐 폭포에서 셜록 홈즈와 제임스 모리어티가 싸워 추락사하고, 홈즈의 귀환까지의 공백 기간으 다룬 얘기.
이 책에서도 셜록 홈즈와 모리어티가 육체적으로 싸워야한 부분을 비꼬는 느낌이 좀 들긴하는데, 어쨌든 그 공백을 훌륭하게 살려낸 느낌. 주인공 격인 애설니 존스와 프레데릭 체이스 조합도 굉장히 잘 맞는 느낌이라 — 홈즈 + 왓슨 만큼 — 흥겹게 읽을 수 있더라.
리뷰: 야경 – 요네자와 호노부
고전부 시리즈 (애니메이션 빙과의 원작) 은 읽었었는데 나오키 상 후보였다는 말 + 알라딘 굿즈 (…) 에 눈이 멀어서 주문해봄. 장편이라고 생각했는데 — 왜 이렇게 착각했는지는 지금도 모르겠음 — 첫 단편인 야경이 휙 하고 끝나버려서 멍.
본격적인 추리물이라고 하기보단 미스테리 물에 가까운 단편들이 수록되어 있다.
고전부 시리즈는 뭔가 굉장히 편안한 일상 미스테리 물이었는데 이건 정말 본격적으로 묵직한(…) 내용이 나옴 — 그러니까 살인, 괴담스러운. 필체도 약간 달라진 느낌이지만 여전히 취향(..)이니 이 작가 책을 몇 개 더 주문해 봐야.
C++1x: std::map 초기화하기
C++03 을 쓰던 시절에 가졌던 불만 중 하나는 std::map 처럼 dictionary 타입을 쓸 때 선언 즉시 초기화하기 번잡한 것. 순서가 중요하지 않을 때 성능이 떨어지는 것도 그렇고. 예를 들어, “Jan” -> 1, “Feb” -> 2, …, “Dec” -> 12 와 같은 관계를 표현하고 싶을 때 C++03 에서 std::map 에 간단히 표현할 방법은 없다. 추가적인 초기화함수를 선언해서 써야한다.
const static std::map<std::string, int> kMonths = InitializeMonthDict(); static std::map<std::string, int> InitializeMonthDict() { std::map<std::string, int> rv; rv.
boost::scoped_ptr 를 기억하십니까?
어제 스마트 포인터 관련 글을 썼는데 여기에서 boost::scoped_ptr 는 다루지 않았다. 그건 scoped_ptr 가 반쯤 구현된 unique_ptr 라서. 두 개의 스마트 포인터의 차이는,
scoped_ptr 는 지금의 unique_ptr 처럼 오직 1명의 소유자 인 코드를 짤 때 유용하다. unique_ptr 는 move 를 적극적으로 활용해서 만들어진 표준 라이브러리다. (C++11) unique_ptr 는 release() 라는 소유권을 포기하는 멤버 함수를 제공한다. 정도다. 그래서 mutable 함수인 release() 만 못쓰게 막으면 되기 때문에 — 즉, const unique_ptr 를 쓰면 되기 때문에, scoped_ptr 의 유용성이 없어진 것.
delete 쓸 일 없는 C++
지난 몇 달간 모 게임의 서버를 새로 만든다고 다시 C++ 을 한창 썼는데, 그 간의 경험을 정리하는 글을 몇 개 써볼까한다.
우선 delete 쓸 일 없는 C++. 적어도 전통적으로 쓰던 “메모리 해제"의 의미 로 delete 를 쓰는 일은 이제 거의 없는 듯 하다. 메모리를 할당하는 순간 (아주 과격하게 말하면) std::unique_ptr 혹은 std::shared_ptr 중 하나에 저장하면 된다. 선택할 때 판단할 근거도 간단하다.
이 메모리를 어느 객체가 가지고 있는지 명확한가 => std::unique_ptr (반대로) 이 메모리를 여러 객체가 공동 소유해야하는가?
맥북 (2015) 사용기
세달쯤 전에 새로 나온 레티나 맥북이 도착. 업무용으로 사서 사용하면서 느낀 점을 기록
무게가 가벼워진건 정말 좋음. 13″ 맥북에어 (2012) 쓰고 있었는데도 확실히 무게가 줄었단 느낌 요즘 밤에 코딩할 때 글자가 잘 안보이고 그랬는데 이런 문제는 해결된듯 메모리가 적다 (8 GiB). 아무리 랩탑이라도 이건 너무 적지 않나. 삼년전부터 쓰던 애도 같은 용량인데… CPU 느림. 삼년전 맥북에어 수준. 요즘 C++ 빌드만 줄창하는데 ccache 아니었다면 해탈했을듯 (cpu는 추가 업그레이드 했음) 디스크는 미묘하게 빨라짐.
연재물 전자책이 개선되면 좋겠다
딱 맥북 / 맥북에어 정도만 들어가는 가방을 들고다니 시작해서, 그리고 늦봄부터는 자전거 통근을 해서; 요즘 통근 중의 책은 거의 리디북스나 레진코믹스에 의존 중. (물론 얇은 문고판 책이나 추가 케이블; 그리고 지갑정도는 들어가지만 그런 책이 항상 있는건 아니라서)
리디북스에서 연재물을 읽고 있는데 — 200화 가까이 연재된 걸 대충 120화부터 따라 잡아서 읽고 있는듯 — 이게 딱히 편하질 않다. 그래서 뭐가 대안일까가 궁금했는데, 최근에 John Scalzi의 신작, End of the all things의 연작 중편을 예약 구매로 사보다가 훨씬 나은 경험을 했다.