Yellowbirds

앞서 작성한 DigiNotar의 가짜 구글 인증서에 이어서 쓰는 글입니다.

IE의 경우 MS에서 windows update를 통해 처리한 것으로 들었습니다. 여기서 처리했다 함은 웹브라우저가 DigiNotar를 Root CA로 인정하지 않도록 하는 것을 말합니다. 심플한 대처지요.

파이어폭스의 경우에도 업데이트를 통해 동일한 처리를 했고, 업데이트가 싫으신 분은 설정에 인증서 관리에 가셔서 직접 제거하셔도 된다고 합니다.

크롬도 마찬가지로 제외시켰다고 했는데, 크롬을 사용하고 있었다면 '혹시 내가 당하지 않았나?'하는 생각을 하지 않아도 됩니다. 왜냐하면 이 사건이 알려진 것이 크롬의 역할이 컸으니까요.

구글의 지메일 포럼에다가 누가 이런 글을 올렸는데, 크롬이 인증서가 이상하다며 경고 메시지를 보내줬다는 것이죠. 그래서 이게 man-in-the-middle attack이 아닌가하고 질문을 했고, 세상에 알려지게 되었습니다.

크롬 입장에서는 은근 자랑할만한 사건이 생긴 것이 되겠네요.

크롬이 경고를 날릴 수 있었던 것은 certificate pinning이라는 개념을 크롬이 도입하고 있어서인데, 개념이라고 하니 무척 고급 기술이 들어간 것 같지만, 별거 아니고, 특정 사이트의 인증서에 대한 root CA 리스트를 강제해두는 것입니다. 좀 더 쉽게 말하면 구글의 인증서를 인증해줄 수 있는 기관은 여기 여기뿐이다라고 정해두는 것이죠. 즉, 사이트별로 root CA whitelist를 가지는 것입니다.

구글은 (2011년 5월 4일 시간 기준으로) 구글 사이트들에 대한 인증을 해줄 수 있는 기관을 Verisign, Google Internet Authority, Equifax, GeoTrust 이렇게 4개의 인증기관으로 한정지어 두고 있습니다. 그러니 DigiNotar가 비록 root CA로써 활동하고 있는 인증 기관임에도 여기서 발행된 *.google.com에 대한 인증서는 크롬 입장에서는 '이상한데?' 하고 의심할 수 있게 되는 것이죠.

안녕하세요? 천재태지 서주영입니다.

EFL 에서 widget 에 해당하는 elementary 라이브러리를 개발하다보면 src/lib 디렉토리에 있는 파일 이름이 왜 els, elc, elm, elu 로 시작하는지 궁금하실겁니다.
이에, 간단히 설명을 해봅니다.

• els : elementary smart object
  elementary 내부적으로 사용하는 smart object 입니다.
  예를 들면, diskselector, entry, gengrid, genlist, list, map, scroller 등의 widget 은 내부적으로 scroller 를 가지고 있습니다. 이 때, scroller 에 해당하는 공통적인 코드를 els_scroller 로 만들어놓은 것이 els widget 입니다. 그리고 이를 다른 widget 이 사용합니다. 즉, els widget 은 elementary 내부에서 공통적으로 사용되는 smart object 입니다. 어플리케이션에서 직접 사용하지 않습니다.
  els_box, els_icon, els_scroller 등이 있습니다. 
  참고로 elm_scroller widget 도 내부적으로 els_scroller 를 사용하고 있습니다.
  
• elm : elementary widget
  일반적인 widget 입니다.
  actionslider, button,  bubble, check, entry, gengrid, genlist, icon, image, label, list 등이 있습니다.
  
• elc : elementary collector widget
  여러 widget 을 합쳐놓은 widget 입니다. 한 widget 이 내부적으로 다른 elm widget 을 사용할 때 주로 쓰이는 용어입니다.
  anchorblock, ctxpopup, fileselector, naviframe 등이 있습니다.
  
• elu : elementary utility
  widget 이라기보다는 편의를 위하여 제공되는 기능입니다. 
  현재는 elu_ews_wm 밖에 없습니다. EWS는 Ecore + Evas Single Process Windowing System 을 의미하며, 이 기능이 활성화 되어 있으면 elementary widget 이 내부적으로 window manager 를 구현해줍니다.  

위 규칙이 엄격하지는 않습니다만, 대략적으로 이 규칙을 따라주면 나중에 코드를 이해하고 사용하기에 좋을 것입니다. 물론 어플리케이션 프로그래머들은 이 규칙을 알 필요가 없습니다.

감사합니다. 

친구(@skyisle)의 페이스북 글에서 가짜 구글 인증서 사건이 있었다는 것을 알게 되었다. DigiNotar라는 곳에서 구글(정확히 말하면 *.google.com)에 대한 인증서를 발행했다는 것이다. DigiNotar는 네덜란드의 인증 기관(certificate authority, CA)이다.

문제는 DigiNotar가 Root CA 중에 하나라는 것인데, 이것이 왜 문제인지 내가 아는데까지 간단히 설명을 해보면,

우선 공개키 방식에 대해서 이해할 필요가 있다. 공개키 방식은 1977년인가에 Diffie와 Hellman이라는 두 사람이 공식적으로 제안한 것으로 유명하다. 그 이전까지는 하나의 키를 두 사람이 남들 모르게 공유하고 이것을 가지고 암호화 및 복호화를 하는 방식에만 모두가 집중하고 있었다. 그래서 키를 어떻게 몰래 나눠가질 것인가가 주요 이슈였다.

서로 뭔가 비밀 정보를 알고 있다면 그것을 이용해서 암호화해서 키를 보내주면 되는데, 뭔가 비밀 정보를 이미 공유하고 있다면 이미 그 자체가 키가 아닌가! 그래서 예전에는 키를 보낼 때 등기 우편으로 보내거나 사람을 사서 안전하게 전달한다는 내용이 논문이 당연하다는 듯이 기술되어 있다. 하지만 이건 사람이 개입되는 것이니 비용이 높고 속도가 느리다. 네트워크를 통해서 쉽게 할 수는 없을까? 하고 당연한 의문이 생겼을 터.

공개키 방식은 말 그대로 키를 공개할 수 있다는 것인데, 그렇게만 된다면 키를 누가 보게 되더라도(즉, 도청을 당할 위협을 고려하지 않고) 필요한 녀석들에게 던져줄 수가 있다. 하지만 공개된 로또 번호가 의미가 없듯, 남들 다 아는 주식 정보가 의미가 없듯, 키가 공개되는 건 이미 그 자체로 의미가 없다.

그럼에도 불구하고 이런 개념이 나올 수 있었던 것은 키가 하나가 아니라 두개이기 때문이다. Key pair를 만들어서 하나는 비밀로 숨기고 하나를 공개한다. 내부적으로 많은 알고리즘이 있을 수 있지만 다음 규칙을 따르면 공개키 방식에 사용될 수 있다.

(1) 공개키로 암호화한 것은 비밀키로 복호화할 수 있다. 반대로,
(2) 비밀키로 암호화한 것은 공개키로 복호화할 수 있다.

첫 번째 방식을 이용해서 안전하게 데이터를 전달하거나 혹은 비밀키를 전달한다.
두 번째 방식을 이용해서 전자서명을 한다.

이것이 디피와 헬만이 제안한 내용이다. 획기적이고 멋진 아이디어지만 여기서 문제가 하나 있다. 공개키가 말 그대로 공개되기 때문에 다른 녀석이 나를 사칭하여 자신의 공개키를 내 것이라고 다른 사람들에게 거짓말을 할 수 있기 때문이다.

즉, A가 B에게 어떤 비밀 메시지를 보내려고 B의 공개키로 암호화를 한다. 그럼 B는 자신만의 비밀키로 풀어서 그 내용을 볼 수가 있다. B의 공개키는 공개되어 있지만 누구도 비밀키는 모르므로 비밀 메시지를 볼 수가 없다.

이 때, E가 B인척 A를 쉽게 속일 수 있다. A가 B의 공개키가 뭔지 알아볼 때 E가 끼어들어 자신의 공개키를 A에게 알려주면서 "이거 B꺼야." 한다. A는 E의 공개키로 암호화 한다. E는 자신의 비밀키로 풀어서 메시지를 쉽게 읽을 수 있다.

이것 때문에 나온 것이 certificate이다. (인증서 개념은 역시 70년대 말에 MIT의 어떤 학부 학생의 졸업 논문에서 제안되었다고 하는데, 학부생이라니! MIT는 MIT다.) 인증 기관이 있어서 이 공개키는 B의 것이 맞소, 하고 인증해주는거다. E가 이것이 B의 인증서이다하면서 자기 인증서를 A에게 들이 밀어도 A가 인증기관에 알아보면 쉽게 이것이 뻥이라는 것을 알 수 있게 된다.

현재 인증서는 누구든 발행할 수 있고 대신에 chain을 형성하면 된다. Chain을 형성해야 한다는 것 자체가 아무나 발생할 수 없다는 소리가 되긴 하지만... 여튼 누군가가 "이 물건이 믿을만한 것이요."라고 말했을 때 못 믿겠다면 그 사람이 믿을만한 사람인지 또 누군가에게 물어봐야 한다. 이렇게 점점 연결 고리가 형성되는데 이 방식대로라면 최후에 절대 신뢰할 수 있는 누군가가 있어야 한다. 뭐, 정부의 인증! KS 마크! 이런 거라고 보면 될까? 비유가 안 좋았다. 하여튼 이걸 Root CA라고 한다.

이야기가 굽이굽이 많이도 돌았다. 결론적으로 하고 싶은 이야기는 DigiNotar는 root CA라서 여기서 발행된 인증서를 봤을 때 사용자는 믿을 수 있다고 생각한다.

이 인증서가 DigiNotar가 직접 발행한 건지 아니면 누군가가 DigiNotar를 해킹해서 한 건지는 내가 본 기사에서는 누구도 다루지 않았지만 여튼 이 인증서는 유효한 인증서였고 이란에 있는 많은 사용자들이 이 가짜 인증서를 사용했다. 아까 말했듯 인증서에는 공개키가 있고 사람들은 이 조작된 공개키를 암호화에 활용했을 것이다. 적발될 때까지 두 달 정도 사용되었다고 하니 꽤 많은 사람들의 지메일이나 구글독스가 털렸을 수도 있겠다.

여기 위키 페이지가 관련 링크로 넘어가기 좋다.

어떻게 적발되었고, 현재는 어떻게 대처하고 있는지는 다음 번으로 미룬다. 힘들다.

 $ svn checkout svn+ssh://{id}@svn.enlightenment.org/var/svn/e/trunk

예) $ svn checkout svn+ssh://seoz@svn.enlightenment.org/var/svn/e/trunk 

[global]

http-proxy-host = 192.168.1.10

http-proxy-port = 8080

원문 링크 : http://jeffhoogland.blogspot.com/2011/06/enlightenment-dr17-and-efls.html

제프 후글랜드 2011/06/10

제 블로그를 봤었다면, 제가 Enlightenment 데스크탑의 열렬한 팬이라는 것을 알고 있을겁니다. Enlightenment 를 사용해보지 않은 분들을 위해 설명을 드리면,

"Enlightenment 는 Linux/X11 등을 위한 윈도우 매니저일뿐만 아니라, 개발 라이브러리 모음이기도 합니다. 이 개발 라이브러리는 기존의 윈도우 매니저는 물론이고 낡은 툴킷을 사용하느라 고생을 하는 대신 쉽게 예쁜 사용자 인터페이스를 작성할 수 있게 해줍니다."

기술과 관련된 이야기를 할 때, 용어를 정확하게 사용해야합니다. 그런데 Enlightenment 와 관련된 이야기를 해보면, 사람들이 Enlightenment, DR17, EFL 을 헷갈려 합니다. 이 세가지는 뭐가 다를까요?

Enlightenment - 프로젝트의 원래 이름입니다. 오늘날 Enlightenment 라고 하면, 특정한 한 부분을 이야기하는게 아니라 이 프로젝트를 전반적으로 가리킵니다.

DR17 - E17 이라고 불리기도 하며, Enlightenment 데스크탑/윈도우 매니저의 최신 버전을 칭합니다. 아직 한참 개발중입니다. 현재 안정된 버전은 DR16 입니다. (역자 주: DR17 은 이름만으로 보면 단지 DR16 의 업버전이라고 오해할 수도 잇지만, 둘은 전혀 다른 윈도우 매니저입니다. 심지어 DR17 을 시작할 때, DR16 의 코드를 한줄도 사용하지 않았습니다.)

EFLs - "Enlightenment Foundation Libraries" 를 뜻하며 Enlightenment 데스크탑에 필요한 기반이 되는 라이브러리 모음입니다. Enlightenment 데스크탑의 핵심 부분이지만 그렇다고 EFL 이 Enlightenment 데스크탑은 아닙니다. (역자 주: Enlightenment 데스크탑이 EFL 라이브러리를 사용합니다.) 쉽게 말해 EFL 과 Enlightenment 데스크탑의 관계는 GTK 와 그놈(Gnome) 그리고 QT 와 KDE 의 관계와 같습니다.

바라건대 여러분이 Enlightenment 의 용어를 이해하는데 도움이 되었으면 좋겠습니다.

~제프 후글랜드