In light of a request on the bugzilla list for more information about how our root certificate is protected I've decided to do a write up here and see if there is anything more people suggest could be done, or a better way of handling things altogether.

W chwili obecnej są 2 serwery - jedne dla stron, drugi dla magazynu certyfikatów, który jest podłączony do serwera stron poprzez kabel szeregowy i z programem działającym bez uprawnień administracyjnych na każdym końcu kabla nasłuchując/nadając zapytania/odpowiedzi.

Jeżeli główny skład wykryje niepoprawna żadanie, przyjmuje że serwer WWW został przejęty przez intruza i wyłącza się.

Jeżeli główny magazyn nie otrzyma odpowiedzi na 'ping' wysłany poprzez łacze szeregowe przez zadany okres czasu, przyjmuje że serwer WWW został przejęty przez intruza lub sam magazyn główny został skradziony i wyłącza się.

Pomijając pliki bootujące, wszystkie dane spoczywają na szyfrowanej partycji serwera głównego (root store) i tylko ręczna interwencja w proces uruchamiania - poprzez wprowadzenie hasła - rozpocznie je na nowo.

The requests sent to the root store, are stored in a file for another process triggered by cron to parse and sign them, then stored in a reply file to be sent back to the webserver. Causing things to be separated into different users, basic privilege separation stuff. So being actually able to hack the serial daemons will only at the VERY worst cause fraudulent certificates, not the root to be revealed.

Why use serial you ask? Well certificate requests are low bandwidth for starters, then of course simpler systems in security are less prone to exploits, and finally serial code is pretty mature and well tested and hopefully all exploits were found and fixed a long time ago.

With the proposed root certificate changes, there would be a new root, this would sign at least 1 sub-root, then the private key stored offline in a bank vault, with the sub-root doing all the signing, or alternatively 2 sub-roots, 1 for client certificates, one for server, the thinking behind this, if any of the sub-roots are compromised they can be revoked and reissued.

Alternatywnie, wraz z postępem, możemy dodawać dodatkowe warstwy zabezpieczeń z powiedzmy 4 serwerami w połączenia z 2 pośrednimi serwerami, porozumiewającymi sie z głównym magazynem i działającymi w systemie pętli tokenowej. Gdy coś poza sekwencją sie dzieje, serwer bezpośredni nadrzędny wyłącza sie i jeśli to by było na miejscu i byłoby więcej ścieżek dostępowych to tym sposobem nastąpiło by przełączenie na serwer z nie naruszonym bezpieczeństwem. Poprostu taki pomysł do przemyśleń.