Версия 1.1.1, 18 юни 2008
Веселин Колев, Софийски Университет "Св. Климент Охридски"
Адрес за кореспонденция: vesso AT vesselin.org
Първоизточник: http://www.vesselin.org
Лиценз на документа: CC Attribution-ShareAlike
Съдържание:
Използване на билетни системи за предотвратяване на колизиите
Защита на обектите в RIPE DB от саботажи, извършвани на база колизии на заявки
Ще бъде разгледана система, която се състои от получател и изпращач. Изпращачът изпраща на получателя инструкции за изпълнение, оформени в съобщение, което се нарича заявка. Получателят изпълнява инструкциите на изпращача само тогава, когато заявките с инструкции са електронно подписани (без значение от сертификатния модел) и подписът върху тях бъде проверен. Проверката на електронния подпис става с помощта на сертификат, копие от който получателя има на разположение в някакво хранилище и са с установена идентичност. Изпращачът изпраща електронно подписаните заявки през среда, която може да бъде разгледана като "черна кутия" - т.е. знае се, че съобщението преминава през "кутията", но всички процеси, които водят до преминаването не са напълно известни и не могат да бъдат моделирани. Подобна среда, за която до известна степен може да бъде прието, че може да се моделира като "черна кутия", относно дадени процеси, е Интернет. При комуникация през тази среда на практика се идентифицира само съставителя на заявката, но не и нейния изпращач. Това значи, че всеки, който има достъп до средата, може да изпрати подписана от друг заявка. Интернет не може да идентифицира (само чрез механизмите за адресация) изпращача на заявки.
Колизия на заявките в система от гореописания тип, се нарича събитие, при което една и съща подписана заявка се изпраща повече от един път до получателя без волята на съставителя й. Ако съставителят е съставил и изпратил до получателя серия от заявки с номера от 1 до N и ако M (M < N или M = N) от тези заявки бъдат записани (прихванати) от друг, който има достъп до средата за обмен (Интернет), то този друг може да изпрати до получателя всяка една от записаните от него M заявки в произволен ред и произволен брoй пъти. Този процес ще бъде наричан "саботаж".
Колизии могат да се реализират дори, ако прихванатите заявки са криптирани. В този случай е достатъчно саботьора да знае, че това наистина са заявки. За тяхното съдържание той може да отгатне по ефекта, който те предизвикват (стига да може да го наблюдава).
Единственият начин за предотвратяване на колизиите е използване на т.нар. "билети". Това са маркери, които имат стойност и подлежат на отчет в базата с данни. Схемата на използване на билети може да се опише така. Този, който ще съставя заявката с инструкции е заявител на билет. Този, който ще получава заявката с инструкции е издател на билет. Издателят на билет поддържа база данни, в която описва издадените билети. Всеки заявител получава електронно подписан билет от издателя му. След това заявителят на билета проверява електронния подпис на издателя и включва билета в съставената заявка с инструкции, подписва заявката и я изпраща към получателя й (който по горното описание е издател на билета). Получателят проверява валидността на изпратената заявка и ако идентификацията на съставителя й бъде проверена успешно, се прави справка в базата с данни за билетите. Ако билетът, който е включен в потвърдената като автентичност заявка фигурира в базата от данни на издателя, но не е използван още, се иницира изпълнението на инструкциите в заявката. След успешното изпълнение на инструкциите, в базата данни се описва факта, че дадения билет е вече използван и нови заявки, в които той е включен се отхвърлят автоматично.
Строго погледнато, получателят на заявката може да не е издател на билета. Възможно е да се използва външна база с билети. Също така е възможно съставителя на заявката да е издател на билета. Възможни са и други вариации на схемата.
RIPE DB е база данни, електронно подписаните заявки към която не използват билетна система по подразбиране. Всички, обекти в RIPE DB, които се упавляват чрез електронно подписани заявки, които се транспортират в Интернет, в общия случай могат да бъдат обект на саботажи. Достатъчно е да се прихванат подписаните заявки към базата от данни и след това да се изпращат в произволен ред и с произволна честота.
Саботьорът може да сдобие с копия от изпратените до RIPE DB подписани заявки по следните четири начина:
подслушване на сесията по изпращането на заявката
Подобно подслушване може да бъде осъществено само, ако съществува възможност за подслушване и записване на трафика на изпращача на заявката (достъп до мрежови комутатори/превключватели, маршрутизатори и т.н). Ако той я изпрати чрез протокол SMTP, т.е. чрез електронно писмо, електронното писмо може да бъде отсято много лесно от записания SMTP трафик за даден. Причината за лесното отсяване на търсените писма из целия записан пощенски поток е, че единствено и само заявките за промяна на обекти в RIPE DB се изпращат към пощенския робот с адрес auto-dbm_at_ripe.net.
подслушване на не-HTTPS сесия на браузъра на изпращача до услугата syncupdate
За да може да се реализира такова подслушване, се изисква много добро планиране. Целта е да се прихване изпратената заявки до услугата syncupdate на RIPE, ако потребителят не използва протокола HTTPS. Подслушващият може да бъде улеснен изключително много, ако изпращачът на заявката използва прокси сървър (по или против волята си) и може да бъде получен несанкциониран достъп до обектите на кеша на прокси сървъра.
взлом на отдалечената система и прочит на локалната файлова система
Ако машината (дори само взломяването на желания потребителския профил), от която се изпращат подписаните заявки бъде взломена, то от локалната файлова система могат да бъдат иззети файловете, в които се намират подписаните заявки, стига те да се съхраняват и да не са криптирани. Това засяга и директории и файлове, които се използват за хранилища от пощенския клиент, с който се изпращат заявките (достатъчно е да се копира директорията съдържаща копие на изпратените писма (обикновено с име "Sent").
взлом на пощенската кутия на изпращача на подписани заявки
Този взлом може да бъде осъществен по няколко начина. Най-лесният е с прихващане на паролата при влизане в кутията, който е особено лесно експлоатируем в случаите, в които изпращащия заявките използва операционни системи Windows и софтуер върху тях. Друг начин за взлом е отгатването на паролата за достъп до кутията (трудна задача). Възможно е да се използва и методика базирана на социалното инженерство, за да се принуди собственика на кутията да разкрие паролата си. Най-успешният начин обаче е проникване в пощенския сървър, на който се намира кутията или в базата с данни, която да съдържа удостоверителната информация, която ползва пощенския сървър, за да удостовери потребителите си.
След като има наличен достъп до кутията, може да се разчита на това, че изпращащият подписаните заявки, съхранява тяхно копие в директорията с изпратени писма (обикновено с име "Sent").
Саботажът се реализира като се възстановяват стари записи (състояния) за обекта в RIPE DB и така се отменят новите. За целта саботьорът, който има копия от подписани заявки, отразяващи различни минали състояния на записите за обекта, може периодично да ги изпраща до RIPE DB и така да връща старото му състояние, което в повечето случаи може да затрудни изключително много собственика на обекта.
Ето пример за това. Саботьорът е прихванал подписана заявка със следното съдържание:
MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="----6D26B6C78CC2C63BA56129867359DD56" This is an S/MIME signed message ------6D26B6C78CC2C63BA56129867359DD56 Content-Type: text/plain mntner: TEST007-MNT descr: for tests only admin-c: VK1242-RIPE tech-c: VK1242-RIPE upd-to: certadmin@certs.lcpe.uni-sofia.bg auth: X509-996 auth: X509-997 mnt-by: TEST007-MNT refferal-by: TEST007-MNT changed: certadmin@certs.lcpe.uni-sofia.bg 20060906 changed: certadmin@certs.lcpe.uni-sofia.bg 20060907 changed: certadmin@certs.lcpe.uni-sofia.bg 20060908 changed: certadmin@certs.lcpe.uni-sofia.bg 20060909 source: RIPE ------6D26B6C78CC2C63BA56129867359DD56 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIKGQYJKoZIhvcNAQcCoIIKCjCCCgYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3 DQEHAaCCBzQwggcwMIIFGKADAgECAgERMA0GCSqGSIb3DQEBBQUAMIHLMQswCQYD VQQGEwJCRzEOMAwGA1UECBMFU29maWExDjAMBgNVBAcTBVNvZmlhMRkwFwYDVQQK ExBPcGVuSW50ZWdyYSBMdGQuMSowKAYDVQQLEyFPcGVuSW50ZWdyYSBDZXJ0aWZp Y2F0ZSBBdXRob3JpdHkxMjAwBgNVBAMTKU9wZW5JbnRlZ3JhIENlcnRpZmljYXRl IGZvciBTdGFmZiBTaWduaW5nMSEwHwYJKoZIhvcNAQkBFhJjYUBvcGVuaW50ZWdy YS5jb20wHhcNMDUxMDEyMTQ1OTQzWhcNMDYxMDEyMTQ1OTQzWjCBojELMAkGA1UE BhMCQkcxDjAMBgNVBAgTBVNvZmlhMQ4wDAYDVQQHEwVTb2ZpYTEYMBYGA1UEChMP T3BlbkludGVncmEgUExDMRowGAYDVQQLExFPcGVuSW50ZWdyYSBTdGFmZjEXMBUG A1UEAxMOVmVzc2VsaW4gS29sZXYxJDAiBgkqhkiG9w0BCQEWFXZlc3NvQG9wZW5p bnRlZ3JhLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqYsTY1 /45/K9579GTyguGqjbydly4ymgsg5IzeyDHzmySfgmastCdKDGNZEYq6NBcpY2RG Til4eellmVnY5E1dbt8j7CmYC74a4Z5iMtEl21ahhdSp1uJz5qP1mDbs5Te30fra SLAUhXVEl85v93bXfHPW8YURtEmehrfM22LJMMrox0JNPl7nKiDVvHkJre97/H6F 4xJwx3S5lPKUPFiMEPt7Qaf+/Fuc+bQ5l1oNE8WuAP+fZo8CGx1CpL8JfhRf4cIT tr6aKilBFHYPD9KC+NnlOydCze0LtrCz7UdYS/TGuNHCu9gbAl5r8Ge3UdEF7fnl O/t9x90Ky7je6QECAwEAAaOCAkQwggJAMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgO4 MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBglghkgBhvhCAQEEBAMC BLAwLAYJYIZIAYb4QgENBB8WHU9wZW5JbnRlZ3JhIFN0YWZmIENlcnRpZmljYXRl MB0GA1UdDgQWBBQGNYQF8doHYzGw3sr8Ijxz466pWTCB6wYDVR0jBIHjMIHggBR1 l4w1Q0Bq6notvNgJbC4sHd8VOaGBxKSBwTCBvjELMAkGA1UEBhMCQkcxDjAMBgNV BAgTBVNvZmlhMQ4wDAYDVQQHEwVTb2ZpYTEZMBcGA1UEChMQT3BlbkludGVncmEg THRkLjEqMCgGA1UECxMhT3BlbkludGVncmEgQ2VydGlmaWNhdGUgQXV0aG9yaXR5 MSUwIwYDVQQDExxPcGVuSW50ZWdyYSBSb290IENlcnRpZmljYXRlMSEwHwYJKoZI hvcNAQkBFhJjYUBvcGVuaW50ZWdyYS5jb22CAQMwQgYJYIZIAYb4QgEEBDUWM2h0 dHA6Ly9jYS5vcGVuaW50ZWdyYS5jb20vY3Jscy9vcGVuaW50ZWdyYS1yb290LmNy bDBDBglghkgBhvhCAQMENhY0aHR0cDovL2NhLm9wZW5pbnRlZ3JhLmNvbS9jcmxz L29wZW5pbnRlZ3JhLXN0YWZmLmNybDAwBglghkgBhvhCAQgEIxYhaHR0cDovL2Nh Lm9wZW5pbnRlZ3JhLmNvbS9wb2xpY3kvMA0GCSqGSIb3DQEBBQUAA4ICAQAIR+mw ihKFbK1rxAy1eCIsb7jNVHM0uP5z8bnmpKUIa1lDHfBQ4T4oi3/Rg3c3rSQfPJ+w C1zmQK90GRIFXc2LSahKAiTxPBRPMEUgEg8dUZzN5iQzOaSGaWF69nWOZOypp8ww JQVvJ04sRfzMOagBOtLjZ7MMcIdDGUeayAtfOTcuw587l+F1hNwszgqmaEpFEx10 qI/B0907j/oVD5h7GJdAn5UbuS7O9mt5NZkfUntks6RnqLdQfuTyywyUvr7EnxZJ XdpaMSih3es7NgnS8pZA207u3NnqHAwqqVembz/uxl8ive+GU87SV6fWTwrVeIB4 Pdu+VQtHdYrvEn58j9UDWm0HBHmtsBqL1qh7w2SX5rP1OdVT2LGkCickmrjl/MKL ydXKp7xrqMDEdE4oVQPr5gzcQXQKU8zFALo1+9eVk9XRhkRLf/2fIFkXwHnip/5H okKYSxYbowa2jBKD2xIgBl/KkpqbJCTDn706MfvDxit2FvekHIoQiUUz5Wlrpsp0 tLJmkYmBZfZNKpRDXdKtsw0qrtjPi31+6uK3mPJ6ylU0eAFoZMq/IBnm6U5ilnoX V5Q9ohEfgoyXpwuANvVzeZ5Qs9rb4SNL9I586jPYrXhMADhRDJuRpGS1mxWKY1Fy HujOS9vC0GQV11+QnYUtDCphyk73IWFRfYMjhjGCAq0wggKpAgEBMIHRMIHLMQsw CQYDVQQGEwJCRzEOMAwGA1UECBMFU29maWExDjAMBgNVBAcTBVNvZmlhMRkwFwYD VQQKExBPcGVuSW50ZWdyYSBMdGQuMSowKAYDVQQLEyFPcGVuSW50ZWdyYSBDZXJ0 aWZpY2F0ZSBBdXRob3JpdHkxMjAwBgNVBAMTKU9wZW5JbnRlZ3JhIENlcnRpZmlj YXRlIGZvciBTdGFmZiBTaWduaW5nMSEwHwYJKoZIhvcNAQkBFhJjYUBvcGVuaW50 ZWdyYS5jb20CAREwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNjA5MTYxMzI2MjdaMCMGCSqGSIb3DQEJBDEW BBSD1/geXCjDUaR+uABA05zC3jf+UDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3 DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQBAUpvo9Y3I52hyPEgaOT+u8or9 ASJct5EnaSP6etd0cgYeSuzuTy2BF1K0Q7HToIkkfpS85V4bLZgeMVEsL3gWvUo7 Q4iWU1V+6iZ4x6GuiTGb4RKVoTWFdNrxL9pL5mXVqYdQ4u7WQS0fvfikWuuZLNQu e3zmvzQI9VDpaph47mJu5v2o+ysd4ClRwuhy3tzBdjdHyRCvtrsride/otdhZHjD j1N5d3NJ7wkhTy9hSs1C8+yHJlpF+WuqEQRBotZzzgNPZhBo4sss+a/IRFa1TkgW 87R2sJjDe+4WnpXCN7hHsPQI0FuGVoMQIUoELdRWAVmc6/YPB/NHpo+QFY4d ------6D26B6C78CC2C63BA56129867359DD56--
Това е някакво старо (вече реализирано) състояние на записите в обекта TEST007-MNT. В него фигурират два управляващи обекта X.509 сертификата, с имена на обекти в RIPE DB съответно X509-996 и X509-997. Собственикът на обекта TEST007-MNT обаче, снема доверието от сертификата с обект X509-997 и за целта изпраща до auto-dbm@ripe.net нова, модифицирана заявка:
MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="----F0C94544BCA587392A7D47BDC2AAEB6A" This is an S/MIME signed message ------F0C94544BCA587392A7D47BDC2AAEB6A Content-Type: text/plain mntner: TEST007-MNT descr: for tests only admin-c: VK1242-RIPE tech-c: VK1242-RIPE upd-to: certadmin@certs.lcpe.uni-sofia.bg auth: X509-996 mnt-by: TEST007-MNT refferal-by: TEST007-MNT changed: certadmin@certs.lcpe.uni-sofia.bg 20060907 changed: certadmin@certs.lcpe.uni-sofia.bg 20060908 changed: certadmin@certs.lcpe.uni-sofia.bg 20060909 changed: certadmin@certs.lcpe.uni-sofia.bg 20060916 source: RIPE ------F0C94544BCA587392A7D47BDC2AAEB6A Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIKGQYJKoZIhvcNAQcCoIIKCjCCCgYCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3 DQEHAaCCBzQwggcwMIIFGKADAgECAgERMA0GCSqGSIb3DQEBBQUAMIHLMQswCQYD VQQGEwJCRzEOMAwGA1UECBMFU29maWExDjAMBgNVBAcTBVNvZmlhMRkwFwYDVQQK ExBPcGVuSW50ZWdyYSBMdGQuMSowKAYDVQQLEyFPcGVuSW50ZWdyYSBDZXJ0aWZp Y2F0ZSBBdXRob3JpdHkxMjAwBgNVBAMTKU9wZW5JbnRlZ3JhIENlcnRpZmljYXRl IGZvciBTdGFmZiBTaWduaW5nMSEwHwYJKoZIhvcNAQkBFhJjYUBvcGVuaW50ZWdy YS5jb20wHhcNMDUxMDEyMTQ1OTQzWhcNMDYxMDEyMTQ1OTQzWjCBojELMAkGA1UE BhMCQkcxDjAMBgNVBAgTBVNvZmlhMQ4wDAYDVQQHEwVTb2ZpYTEYMBYGA1UEChMP T3BlbkludGVncmEgUExDMRowGAYDVQQLExFPcGVuSW50ZWdyYSBTdGFmZjEXMBUG A1UEAxMOVmVzc2VsaW4gS29sZXYxJDAiBgkqhkiG9w0BCQEWFXZlc3NvQG9wZW5p bnRlZ3JhLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqYsTY1 /45/K9579GTyguGqjbydly4ymgsg5IzeyDHzmySfgmastCdKDGNZEYq6NBcpY2RG Til4eellmVnY5E1dbt8j7CmYC74a4Z5iMtEl21ahhdSp1uJz5qP1mDbs5Te30fra SLAUhXVEl85v93bXfHPW8YURtEmehrfM22LJMMrox0JNPl7nKiDVvHkJre97/H6F 4xJwx3S5lPKUPFiMEPt7Qaf+/Fuc+bQ5l1oNE8WuAP+fZo8CGx1CpL8JfhRf4cIT tr6aKilBFHYPD9KC+NnlOydCze0LtrCz7UdYS/TGuNHCu9gbAl5r8Ge3UdEF7fnl O/t9x90Ky7je6QECAwEAAaOCAkQwggJAMAkGA1UdEwQCMAAwCwYDVR0PBAQDAgO4 MB0GA1UdJQQWMBQGCCsGAQUFBwMCBggrBgEFBQcDBDARBglghkgBhvhCAQEEBAMC BLAwLAYJYIZIAYb4QgENBB8WHU9wZW5JbnRlZ3JhIFN0YWZmIENlcnRpZmljYXRl MB0GA1UdDgQWBBQGNYQF8doHYzGw3sr8Ijxz466pWTCB6wYDVR0jBIHjMIHggBR1 l4w1Q0Bq6notvNgJbC4sHd8VOaGBxKSBwTCBvjELMAkGA1UEBhMCQkcxDjAMBgNV BAgTBVNvZmlhMQ4wDAYDVQQHEwVTb2ZpYTEZMBcGA1UEChMQT3BlbkludGVncmEg THRkLjEqMCgGA1UECxMhT3BlbkludGVncmEgQ2VydGlmaWNhdGUgQXV0aG9yaXR5 MSUwIwYDVQQDExxPcGVuSW50ZWdyYSBSb290IENlcnRpZmljYXRlMSEwHwYJKoZI hvcNAQkBFhJjYUBvcGVuaW50ZWdyYS5jb22CAQMwQgYJYIZIAYb4QgEEBDUWM2h0 dHA6Ly9jYS5vcGVuaW50ZWdyYS5jb20vY3Jscy9vcGVuaW50ZWdyYS1yb290LmNy bDBDBglghkgBhvhCAQMENhY0aHR0cDovL2NhLm9wZW5pbnRlZ3JhLmNvbS9jcmxz L29wZW5pbnRlZ3JhLXN0YWZmLmNybDAwBglghkgBhvhCAQgEIxYhaHR0cDovL2Nh Lm9wZW5pbnRlZ3JhLmNvbS9wb2xpY3kvMA0GCSqGSIb3DQEBBQUAA4ICAQAIR+mw ihKFbK1rxAy1eCIsb7jNVHM0uP5z8bnmpKUIa1lDHfBQ4T4oi3/Rg3c3rSQfPJ+w C1zmQK90GRIFXc2LSahKAiTxPBRPMEUgEg8dUZzN5iQzOaSGaWF69nWOZOypp8ww JQVvJ04sRfzMOagBOtLjZ7MMcIdDGUeayAtfOTcuw587l+F1hNwszgqmaEpFEx10 qI/B0907j/oVD5h7GJdAn5UbuS7O9mt5NZkfUntks6RnqLdQfuTyywyUvr7EnxZJ XdpaMSih3es7NgnS8pZA207u3NnqHAwqqVembz/uxl8ive+GU87SV6fWTwrVeIB4 Pdu+VQtHdYrvEn58j9UDWm0HBHmtsBqL1qh7w2SX5rP1OdVT2LGkCickmrjl/MKL ydXKp7xrqMDEdE4oVQPr5gzcQXQKU8zFALo1+9eVk9XRhkRLf/2fIFkXwHnip/5H okKYSxYbowa2jBKD2xIgBl/KkpqbJCTDn706MfvDxit2FvekHIoQiUUz5Wlrpsp0 tLJmkYmBZfZNKpRDXdKtsw0qrtjPi31+6uK3mPJ6ylU0eAFoZMq/IBnm6U5ilnoX V5Q9ohEfgoyXpwuANvVzeZ5Qs9rb4SNL9I586jPYrXhMADhRDJuRpGS1mxWKY1Fy HujOS9vC0GQV11+QnYUtDCphyk73IWFRfYMjhjGCAq0wggKpAgEBMIHRMIHLMQsw CQYDVQQGEwJCRzEOMAwGA1UECBMFU29maWExDjAMBgNVBAcTBVNvZmlhMRkwFwYD VQQKExBPcGVuSW50ZWdyYSBMdGQuMSowKAYDVQQLEyFPcGVuSW50ZWdyYSBDZXJ0 aWZpY2F0ZSBBdXRob3JpdHkxMjAwBgNVBAMTKU9wZW5JbnRlZ3JhIENlcnRpZmlj YXRlIGZvciBTdGFmZiBTaWduaW5nMSEwHwYJKoZIhvcNAQkBFhJjYUBvcGVuaW50 ZWdyYS5jb20CAREwCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0wNjA5MTYxMzI2NDBaMCMGCSqGSIb3DQEJBDEW BBTXeGg5SF6eZNO1uwMpJ0rtB02ocjBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3 DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASCAQBCohwo/vEpw5HThRprZuiiy1SJ cjc8B0pjqqB0CnDJhD7pl/Gstux6gu/S7e136V/Wz8D9/xqd+rkDzd1ZBuIr/oKK OG1h7n1/xq7iErQKgqTWaohW+AyyMYO7kcUKD5G3GZ8pfuA4EIKnYPPMCcXnNxdM pgCHDmfK5o6OZH/MEjyAASh6oHGo+D74FAjl5PgGF6bXXxnenqFV08dxcZW59N70 +aGFZ3CIh/kDqiIiZxkzYYfAv4nIw0J7+f48wqt3IIOJokFxy5Ei3XRKY8vDcVga ok11+x8FhjvsCP7E3CXwtF6EbNCaP1qj/3EwkxprsIViLycpelY2V4CFAqKQ ------F0C94544BCA587392A7D47BDC2AAEB6A--
Ако след това саботьорът изпрати до auto-dbm@ripe.net прихваната от него стара заявка, той може да възстанови обекта TEST007-MNT в предишното му състояние, в което права за управление върху него е имал обекта X509-997. Това може да доведе дори до превземането на обекта (особено ако доверието върху обекта X509-997 е снето поради разкриване на частния ключ към сертификата намиращ се в този обект и саботьора притежава копие от него).
RIPE са съдали уеб базирания инструмент syncupdate. Неговият вариант syncupdate-minimal, достъпен през протокол HTTPS е вид билетна система за изпращане на заявки за обновяване на управление на обекти в RIPE DB.
Syncupdate-minimal представлява една опростена форма за изпращане на предварително генерирани електронно подписани заявки към RIPE DB (макар да може да се използва и за подаване на заявки чрез удостоверяване с парола). Ето и изглед от формата, заедно с въведена в нея примерна подписана заявка в MIME формат:
С натискане на бутона "Submit", подписаната заявка се изпраща през криптиран канал до обработчика на заявки на RIPE DB.
Нужно е да се обясни защо syncupdate-minimal, използван през HTTPS, е билетна система за електронно подписани заявки. На пръв поглед не се забелязва обмен на билети. Това обаче е привидно. Ако се разгледа детайлно криптографският протокол SSLv3, който е в основата на приложния протокол HTTPS, се забелязва една важна особеност. Тази особеност се състои в това, че в рамките на криптографския протокол SSLv3 между клиента и сървъра се обменя случайно генериран сесиен ключ, който криптира обменяните данни чрез криптографски алгоритъм със симетричен ключ (например 3DES, AES256 и др). Този сесиен ключ е именно билета. На практика билетът в този случай се генерира от клиента (браузъра) и след това се изпраща в криптиран вид до сървъра (криптиран с публичния ключ от X.509 сертификата на сървъра), а не от сървъра. Ако някой прихваща трафика между браузъра и уеб сървъра и дори знае, точно каква информация се обмента в сесията, той няма да може да я използва за злонамерени цели. Причината е, че той не знае сесийния ключ (който в схемата е и билет).
За да бъде syncupdate-minimal сигурна билетна система за обмен, е нужно за изпращане на заявките да се използва проверено невзломена работна станция и софтуер, а заявките след генерирането им и изпращането им до сървъра, да се криптират (или унищожават).
Версия 1.1: [tar.gz] [електронен подпис върху архива]
Публикувана на: 14 октомври 2007г.
Този документ е с OpenPGP подписано съдържание
[информация] [електронен подпис][TimeStamp]
