윈디하나의 누리사랑방. 이런 저런 얘기
CVE-2015-0235 GHOST
하트블리드
구글, 암호화 체계 강화
※ 구글이 자사의 암호화 체계를 강화한다고 하네요. 몇달전 구글이 사용자의 이메일을 엿본다(?)고 말한 기사와 비교됩니다만, 저건 환영하는 일이긴 합니다. (엿본다는게 메일을 읽는다는게 아니라, 키워드를 추출해 광고에 활용한다는 이야기입니다. 이는 라이선스 어그리먼트에 나와 있습니다)
※ 예전에 스노든이란 사람이 폭로한게 있습니다. 정보기관에서, 인터넷으로 전달되는 정보를 엿본다는 것이죠. 현재 암호화 표준 방법으로 암호화된 정보는 쉽고 빠른 방법으로 풀 수 있는 방법은 없습니다. 수학적으로 증명된 내용이죠. 하지만 느린 방법으로 풀 방법은 있습니다. 슈퍼 컴퓨터를 사용하면 느린 속도가 커버되니 방법은 있는 셈입니다. 이런걸 정보기관이 한다는건 익히 알려져 있는 사실이긴 합니다. 게다가 추측이긴 합니다만 몇몇 사이트의 개인키를 정보기관에서 가지고 있다고도 알려져 있습니다. 해커에 의해 개인키가 유출되어도 소용없도록 만들기 위해 DHE나 ECDHE와 같은 키 교환 알고리즘도 나오구요.
※ 그런데 다른 방법이 있습니다. 암호화된 데이터는 사용자에게 보여줄 때 복호화하게 마련입니다. 이 복호화 한걸 가로채서 엿본다는 내용입니다. 암호 해독에 필요한 비용이 획기적으로 줄어드는 셈입니다.
※ 이게 문제가 되니까 구글도 이런 부분을 신경서서 암호화 체계를 강화하겠다는 겁니다. 정부기관에서 자신의 메일을 보고 있다는걸 알면 인터넷을 사용하려는 사람이 줄 가능성도 있으니까요. 구글로써는 반갑지만은 않은 일이겠죠.
※ 전 대부분의 정보를 자체적으로 운영하는 서버에 저장하고 있습니다. 딱히 공개 못할 정보가 있는건 아닙니다만, 그래도 위와 같은 기분 나쁜 문제를 겪고 싶지는 않네요.
----
윈도7, IE에서 ECDHE 알고리즘 사용하기: http://windy.luru.net/1620
TLS 1.2
- TLS(Transport Layer Security)는 인터넷 프로토콜 암호화 규격이라고 이해하면 쉽다. 예전(2000년대 초)에는 SSL(Secure Sockets Layer)도 많이 사용되었지만 현재는 TLS를 권장하고 있다. SSL은 v3.0 까지 나와있지만, v3.0에서도 보안에 문제가 있기 때문에 SSL을 사용하는 것은 권장하지 않는다.
- 윈도 7의 익스플로러 9에서는 TLS 1.1, TLS 1.2가 비활성화 되어있다. 이 글을 쓰는 시점에서 TLS 1.2를 지원하는 브라우저가 별로 없는데, 윈도에서는 오페라와 사파리가 있다. 사파리의 경우 최근에서야 지원하기 시작했으며 크롬도 최근 업데이트부터 TLS 1.1을 지원한다. 파이어폭스는 아직 지원하지 않는다.
- 어쩄든 윈도 7의 익스플로러 9에서는 TLS를 활성화 할 수 있다. 아래와 같이 인터넷 옵션에서 바꿔주면 된다.
IE9의 TLS 1.1, TLS 1.2세팅 화면. 인터넷 옵션 화면에서 고급 탭에 있다.
- 예전엔 Apache-OpenSSL 조합의 웹 서버에서 TLS 1.2를 지원하지 못했는데, 2012년 초에 OpenSSL 1.0.1 이 나오면서 TLS 1.2를 지원하기 시작했다. 즉 2011년에는 브라우저에서 TLS 1.2를 지원해도 서버에서 지원하지 못하는 경우가 많았다는 의미다. 지금은 서버, 클라이언트 모두 지원할 수 있는 환경이 갖춰져 있으니 TLS 1.2를 활성화 해놓는게 좋을 것이다.
- TLS 1.1은 TLS 1.0에 비해 많은 것이 바뀌었다. 이 변경점은 CBC에서 예상되는 문제를 보완하기 위해 변경했기 때문에 반드시 TLS 1.0 대신 TLS 1.2을 사용해야 한다. (이를 이용한 TLS 1.0에 대한 취약점은 BEAST 패치를 통해 해결할 수 있다. TLS1.0 을 지원하는 대부분의 브라우저는 패치되어있을 것이다. 참고로 TLS 1.0과 SSL 3.0은 사실상 같은 프로토콜이다) TLS 1.2는 SHA-1을 사용하던 해시 알고리즘을 SHA-256으로 변경하고, 다양한 알고리즘을 수용할 수 있도록 변경되었다.
----
2014.08.29 업데이트: 현재는 대부분의 브라우저에서 TLS 1.2를 지원하고 있다. ECDHE나 GCM 같은 알고리즘도 지원해준다. TLS 1.2 은 아직까지는 보안 결함이 없는 것으로 알려져 있다. 반대로, TLS 1.1도 지금 단계에서는 안심할 수 있는 단계가 아니다. 일부 취약점들이 보고되고 있다고 한다.
ECC vs Non-ECC
DRAM 과 같은 메모리는 우주선 또는 알파선(X선보다 강한 빛)에 의해 비트의 값이 변경된다. 특히 공정이 미세화될 수록 작은 에너지에도 비트의 값이 변경될 수 있는데, 미세 공정을 사용하고 집적도가 높아지면 이 빈도가 꽤 잦은 편이다.
통상 10~100 FIT/MB정도의 비율로 알려져 있다. (이 값은 지구 자기장, 고도, 서버가 놓인 곳의 차폐정도, 태양의 활동 등에 의해 변하며 인공적인 방사선원 근처, 예를 들면 원자력 발전소 옆이면 비율이 훨씬 더 높아진다) 1 FIT는 10억 시간동안 1개의 디바이스 실패를 나타낸다. 쉽게 말하면 100GB메모리를 가지고 있으면 100~1000시간이 지나면 1회 발생하는 비율이라는 의미다 - 생각보다 흔한 일이다.
변경되는 현상중 90%는 1비트만 변하고, 나머지는 2비트 이상 변한다. 메모리 모듈에 ECC(Error Correction Code)기능이 있으면 1비트가 변했을 때 이를 감지해내고 정정할 수 있다. 2비트 이상 변했다면 감지는 해내지만 고쳐주지는 못한다. ECC가 없다면 이런 형태의 오류에 대해 감지할 수도, 정정할 수도 없다. 따라서 중요한 데이터를 다루는 서버급 장비에는 ECC가 반드시 필요하다.
메모리 모듈은 보통 64비트 단위로 작동한다. ECC메모리 모듈은 여기에 8비트 ECC가 붙어, 72비트가 된다. 또한 ECC메모리와 Non-ECC 메모리는 물리적으로는 호환된다. 따라서 메모리 컨트롤러에서 ECC를 지원해준다면, DDR4 까지는 메모리 소켓 변경이 필요 없기 때문에 데스크탑 마더보드에서도 ECC메모리를 사용할 수 있다. (여기서 말하는 ECC 메모리는 "ECC Unbuffered 메모리"이다)
삼성 DDR4 REG ECC 메모리. 메모리 칩이 7개로 하나는 ECC를 위해 붙어있다. 가운데 붙어있는 작은 칩은 REG구현을 위해 붙어있는 버퍼용 칩이다.