Инфраструктура открытых ключей. Цепочка корневых сертификатов X509 v.3 / forpes.ru

Главная
Инфраструктура открытых ключей. Цепочка корневых сертификатов X509 v.3

Инфраструктура открытых ключей. Цепочка корневых сертификатов X509 v.3 +12

16.01.2019 17:05

saipr 44 3600 Источник

Неумолимо приближается час «Ч»: «использование схемы подписи ГОСТ Р 34.10-2001 для формирования подписи после 31 декабря 2018 года не допускается!».

Однако потом что-то пошло не так, кто-то оказался не готов, и использование ГОСТ Р 34.10-2001 продлили на 2019 год. Но вдруг все бросились переводить УЦ на ГОСТ Р 34.10-2012, а простых граждан переводить на новые сертификаты. У людей на руках стало по нескольку сертификатов. При проверки сертификатов или электронной подписи стали возникать вопросы, а где взять корневые сертификаты, чтобы установить в хранилища доверенных корневых сертификатов.

Это касается как хранилища сертификатов в Windows, так и хранилища сертификатов в браузерах Firefox и Google Chrome, GnuPG, LibreOffice, почтовых клиентах и даже OpenSSL. Конечно, надо было озаботиться этим при получении сертификата в УЦ и записать цепочку сертификатов на флешку. А с другой стороны у нас же цифровое общество и в любой момент должна быть возможность получить эту цепочку из сети. Как это сделать на страницах Хабра показал simpleadmin. Однако для рядового гражданина это все же сложновато (особенно, если иметь ввиду, что абсолютное их большинство сидит на Windows): нужно иметь «какой-то» openssl, утилиту fetch, которой и у меня не оказалось на компьютере, и далеко не каждый знает, что вместо нее можно использовать wget. А сколько действий нужно выполнить. Выход конечно есть, написать скрипт, но не просто скрипт поверх openssl и иже с ним, а упакованный в самодостаточный выполняемый модуль для различных платформ.

На чем писать никаких сомнений не было – на Tcl и Python. И начинаем с Tcl и вот почему:

* охренительной вики, где есть даже игрушки (там можно подсмотреть интересное :)
* шпаргалки
* нормальные сборки tclkit (1.5 — 2 Мб как плата за реальную кросс-платформенность)
* и моя любимая сборка eTcl от Evolane (бережно сохранённая с умершего сайта :(
сохраняют высокий рейтинг Tcl/Tk в моём личном списке инструментария
и, да, wiki.tcl.tk/16867 (мелкий web-сервер с cgi на Tcl, периодически используется с завидным постоянством под tclkit)
а ещё — это просто красиво и красиво :)

К этому бы я добавил наличии утилиты freewrap, которая нам и поможет собрать автономные (standalone) утилиты для Linux и MS Windows. В результате мы будем иметь утилиту chainfromcert:

bash-4.3$ ./chainfromcert_linux64  
Copyright(C)2019 
Usage: 
chainfromcert <file with certificate> <directory for chain certificate> 
Bad usage! 
bash-4.3$

В качестве параметров утилите задаются файл с пользовательским сертификатом (как в формате PEM, так и формате DER) и каталог, в котором будут сохранены сертификаты УЦ, входящие в цепочку:

bash-4.3$ ./chainfromcert_linux64  ./cert_test.der /tmp
Loading file: cert_test.der 
Directory for chain: . 
cert 1 from http://ca.ekey.ru/cdp/ekeyUC2012.cer 
cert 2 from http://reestr-pki.ru/cdp/guc_gost12.crt 
Goodby! 
Length chain=2 
Copyright(C) 2019
bash-4.3$

А теперь рассмотрим как работает утилита.
Информация о центре сертификации, выдавшем сертификат пользователю, хранится в расширении с oid-ом 1.3.6.1.5.5.7.1.1. В этом расширении может хранится как о местонахождении сертификата УЦ (oid 1.3.6.1.5.5.7.48.2), так и информация о службе OCSP УЦ (oid 1.3.6.1.5.5.7.48.1):

А информация, например, о периоде использования ключа электронной подписи хранится в расширении с oid-ом 2.5.29.16.

Для разбора сертификата и доступа к расширениям сертификата воспользуемся пакетом pki:

#!/usr/bin/tclsh -f
package require pki

Нам также потребуются пакет base64:

package require base64

Пакет pki, а также подгружаемые им пакет asn, и пакет base64 и помогут нам преобразовывать сертификаты из PEM-кодировки в DER-кодировку, разобрать ASN-структуры и собственно получить доступ к информации о местонахождении сертификатов УЦ.

Работа утилиты начинается с проверки параметров и загрузки файла с сертификатом:

proc usage {use } {
    puts "Copyright(C) LISSI-Soft Ltd (http://soft.lissi.ru) 2011-2019"
    if {$use == 1} {
	puts "Usage:\nchainfromcert <file with certificate> <directory for chain certificate>\n"
    }
}
if {[llength $argv] != 2 } {
    usage 1
    puts "Bad usage!"
    exit
}
set file [lindex $argv 0]
if {![file exists $file]} {
    puts "File $file not exist"
    usage 1
    exit
}
puts "Loading file: $file"
set dir [lindex $argv 1]
if {![file exists $dir]} {
    puts "Dir $dir not exist"
    usage 1
    exit
}
puts "Directory for chain: $dir"
set fd [open $file]
chan configure $fd -translation binary
set data [read $fd]
close $fd
if {$data == "" } {
    puts "Bad file with certificate=$file"
    usage 1
    exit
}

Здесь все понятно и отметим только одно – файл с сертификатом рассматривается как бинарный файл:

chan configure $fd -translation binary

Это связано с тем, что сертификат может хранится как в формате DER (двоичный код), так и в формате PEM (base64 — кодировка).

После того как файл загружен вызывается процедура chainfromcert:

set depth [chainfromcert $data $dir]

которая собственно и загружает корневые сертификаты:

proc chainfromcert {cert dir} {
    if {$cert == "" } {
	exit
    }
    set asndata [cert_to_der $cert]
    if {$asndata == "" } {
#Файл содержит все что угодно, только не сертификат
	return -1
    }
    array set cert_parse [::pki::x509::parse_cert $asndata]
    array set extcert $cert_parse(extensions)
    if {![info exists extcert(1.3.6.1.5.5.7.1.1)]} {
#В сертификате нет расширений
	return 0
    }
    set a [lindex $extcert(1.3.6.1.5.5.7.1.1) 0]
#    if {$a == "false"} {
#	puts $a
#    }
#Читаем ASN1-последовательность расширения в Hex-кодировке
    set b [lindex $extcert(1.3.6.1.5.5.7.1.1) 1]
#Переводим в двоичную кодировку
    set c [binary format H* $b]
#Sequence 1.3.6.1.5.5.7.1.1
    ::asn::asnGetSequence c c_par_first
#Цикл перебора значений в засширении 1.3.6.1.5.5.7.1.1
    while {[string length $c_par_first] > 0 } {
#Выбираем очередную последовательность (sequence)
	::asn::asnGetSequence c_par_first c_par
#Выбираем oid из последовательности
	::asn::asnGetObjectIdentifier c_par c_type
	set tas1 [::pki::_oid_number_to_name $c_type]
#Выбираем установленное значение
	::asn::asnGetContext c_par c_par_two
#Ищем oid с адресом корневого сертификата
	if {$tas1 == "1.3.6.1.5.5.7.48.2" } {
#Читаем очередной корневой сертификат
	    set certca [readca $c_par $dir]
	    if {$certca == ""} {
#Прочитать сертификат не удалось. Ищем следующую точку с сертификатом
		continue
	    } else {
		global count
#Сохраняем корневой сертификат в указанном каталоге
		set f [file join $dir [file tail $c_par]]
		set fd [open $f w]
		chan configure $fd -translation binary
		puts -nonewline $fd $certca 
		close $fd
		incr count
		puts "cert $count from $c_par"
#ПОДЫМАЕМСЯ по ЦЕПОЧКЕ СЕРТИФИКАТОВ ВВЕРХ
		chainfromcert $certca $dir
		continue
	    }
	} elseif {$tas1 == "1.3.6.1.5.5.7.48.1" } {
#	    puts "OCSP server (oid=$tas1)=$c_par"
	}
    }
# Цепочка закончилась
    return $count
}

К комментариям добавить нечего, но у нас осталась не рассмотренной процедура readca:

proc readca {url dir} {
    set cer ""
#Читаем сертификат в бинарном виде
    if {[catch {set token [http::geturl $url -binary 1]
#получаем статус выполнения функции
	set ere [http::status $token]
	if {$ere == "ok"} {
#Получаем код возврата с которым был прочитан сертификат
	    set code [http::ncode $token]
	    if {$code == 200} {
#Сертификат успешно прочитан и будет созвращен
                set cer [http::data $token]
    	    } elseif {$code == 301 || $code == 302} {
#Сертификат перемещен в другое место, получаем его 
         		set newURL [dict get [http::meta $token] Location]
#Читаем сертификат с другого сервера
          		set cer [readca $newURL $dir]
    	    } else {
#Сертификат не удалось прочитать
        	set cer ""
    	    }
        } 
    } error]} {
#Сертификат не удалось прочитать, нет узла в сети
	set cer ""
    }
    return $cer
}

Это процедура построена на использовании пакета http:

package require http

Для чтения сертификата мы используем следующую функцию:

set token [http::geturl $url -binary 1]

Назначение остальных используемых функции понятно из комментариев. Дадим только расшифровку кодов возврата для функции http::ncodel:

200 Запрос успешно выполнен
206 Запрос успешно выполнен, но удалось скачать только часть файла
301 Файл перемещен в другое место
302 Файл временно перемещен в другое место
401 Требуется аутентификация на сервере
403 Доступ к этому ресурсу запрещен
404 Указанный ресурс не может быть найден
500 Внутренняя ошибка

Осталось не рассмотренной одна процедура, а именно cert_to_der:

proc cert_to_der {data} {
    set lines [split $data \n]
    set hlines 0
    set total 0
    set first 0
#Ищем PEM-сертификат в файле
    foreach line $lines {
        incr total
        if {[regexp {^-----BEGIN CERTIFICATE-----$} $line]} {
            if {$first} {
                incr total -1
                break
            } else {
                set first 1
                incr hlines
            }
        }        
        if {[regexp {^(.*):(.*)$} $line ]} {
            incr hlines
        } 
    }
    if { $first == 0 && [string range $data 0 0 ] == "0" } {
#Очень похоже на DER-кодировку "0" == 0x30 
	return $data
    }
    if {$first == 0} {return ""}
    set block [join [lrange $lines $hlines [expr {$total-1}]]]
#from PEM to DER
    set asnblock [base64::decode $block]
    return $asnblock
}

Схема процедуры очень простая. Если это PEM-файл с сертификатом («-----BEGIN CERTIFICATE----- »), то выбирается тело этого файла и преобразуется в бинаоный код:

set asnblock [base64::decode $block]

Если это не PEM-файл, то проверяется это «похожесть» на asn-кодировку (нулевой бит должен быть равен 0x30).

Вот собственно и все, осталось добавить завершающие строки:

if {$depth == -1} {
    puts "Bad file with certificate=$file"
    usage 1
    exit
}
puts "Goodby!\nLength chain=$depth"
usage 0
exit

Теперь все собираем в один файл с именем

chainfromcert.tcl

#!/usr/bin/tclsh
encoding system utf-8

package require pki
package require base64
#package require asn
package require http 
global count
set count 0

proc chainfromcert {cert dir} {
    if {$cert == "" } {
	exit
    }
    set asndata [cert_to_der $cert]
    if {$asndata == "" } {
#Файл содержит все что угодно, только не сертификат
	return -1
    }
    array set cert_parse [::pki::x509::parse_cert $asndata]
    array set extcert $cert_parse(extensions)
    if {![info exists extcert(1.3.6.1.5.5.7.1.1)]} {
#В сертификате нет расширений
	return 0
    }
    set a [lindex $extcert(1.3.6.1.5.5.7.1.1) 0]
#    if {$a == "false"} {
#	puts $a
#    }
#Читаем ASN1-последовательность расширения в Hex-кодировке
    set b [lindex $extcert(1.3.6.1.5.5.7.1.1) 1]
#Переводим в двоичную кодировку
    set c [binary format H* $b]
#Sequence 1.3.6.1.5.5.7.1.1
    ::asn::asnGetSequence c c_par_first
#Цикл перебора значений в засширении 1.3.6.1.5.5.7.1.1
    while {[string length $c_par_first] > 0 } {
#Выбираем очередную последовательность (sequence)
	::asn::asnGetSequence c_par_first c_par
#Выбираем oid из последовательности
	::asn::asnGetObjectIdentifier c_par c_type
	set tas1 [::pki::_oid_number_to_name $c_type]
#Выбираем установленное значение
	::asn::asnGetContext c_par c_par_two
#Ищем oid с адресом корневого сертификата
	if {$tas1 == "1.3.6.1.5.5.7.48.2" } {
#Читаем очередной корневой сертификат
	    set certca [readca $c_par $dir]
	    if {$certca == ""} {
#Прочитать сертификат не удалось. Ищем следующую точку с сертификатом
		continue
	    } else {
		global count
#Сохраняем корневой сертификат в указанном каталоге
		set f [file join $dir [file tail $c_par]]
		set fd [open $f w]
		chan configure $fd -translation binary
		puts -nonewline $fd $certca 
		close $fd
		incr count
		puts "cert $count from $c_par"
#ПОДЫМАЕМСЯ по ЦЕПОЧКЕ СЕРТИФИКАТОВ ВВЕРХ
		chainfromcert $certca $dir
		continue
	    }
	} elseif {$tas1 == "1.3.6.1.5.5.7.48.1" } {
#	    puts "OCSP server (oid=$tas1)=$c_par"
	}
    }
# Цепочка закончилась
    return $count
}

proc readca {url dir} {
    set cer ""
#Читаем сертификат в бинарном виде
    if {[catch {set token [http::geturl $url -binary 1]
#получаем статус выполнения функции
	set ere [http::status $token]
	if {$ere == "ok"} {
#Получаем код возврата с которым был прочитан сертификат
	    set code [http::ncode $token]
	    if {$code == 200} {
#Сертификат успешно прочитан и будет созвращен
                set cer [http::data $token]
    	    } elseif {$code == 301 || $code == 302} {
#Сертификат перемещен в другое место, получаем его 
         		set newURL [dict get [http::meta $token] Location]
#Читаем сертификат с другого сервера
          		set cer [readca $newURL $dir]
    	    } else {
#Сертификат не удалось прочитать
        	set cer ""
    	    }
        } 
    } error]} {
#Сертификат не удалось прочитать, нет узла в сети
	set cer ""
    }
    return $cer
}

proc cert_to_der {data} {
    set lines [split $data \n]
    set hlines 0
    set total 0
    set first 0
#Ищем PEM-сертификат в файле
    foreach line $lines {
        incr total
#        if {[regexp {^-----(.*?)-----$} $line]} {}
        if {[regexp {^-----BEGIN CERTIFICATE-----$} $line]} {
            if {$first} {
                incr total -1
                break
            } else {
                set first 1
                incr hlines
            }
        }        
        if {[regexp {^(.*):(.*)$} $line ]} {
            incr hlines
        } 
    }
    if { $first == 0 && [string range $data 0 0 ] == "0" } {
#Очень похоже на DER-кодировку "0" == 0x30 
	return $data
    }
    if {$first == 0} {return ""}
    set block [join [lrange $lines $hlines [expr {$total-1}]]]
#from PEM to DER
    set asnblock [base64::decode $block]
    return $asnblock
}

proc usage {use } {
    puts "Copyright(C) LISSI-Soft Ltd (http://soft.lissi.ru) 2011-2019"
    if {$use == 1} {
	puts "Usage:\nchainfromcert <file with certificate> <directory for chain certificate>\n"
    }
}
if {[llength $argv] != 2 } {
    usage 1
    puts "Bad usage!"
    exit
}
set file [lindex $argv 0]
if {![file exists $file]} {
    puts "File $file not exist"
    usage 1
    exit
}
puts "Loading file: $file"
set dir [lindex $argv 1]
if {![file exists $dir]} {
    puts "Dir $dir not exist"
    usage 1
    exit
}
puts "Directory for chain: $dir"
set fd [open $file]
chan configure $fd -translation binary
set data [read $fd]
close $fd
if {$data == "" } {
    puts "Bad file with certificate=$file"
    usage 1
    exit
}
set depth [chainfromcert $data $dir]
if {$depth == -1} {
    puts "Bad file with certificate=$file"
    usage 1
    exit
}
puts "Goodby!\nLength chain=$depth"
usage 0
exit

Проверить работу этого файла можно с помощью интерпретарора tclsh:

$ tclsh ./chainfromcert.tcl cert_orlov.der /tmp 
Loading file: cert_test.der 
Directory for chain: /tmp 
cert 1 from http://ca.ekey.ru/cdp/ekeyUC2012.cer 
cert 2 from http://reestr-pki.ru/cdp/guc_gost12.crt 
Goodby! 
Length chain=2 
Copyright(C) 2019 
$

В результате работы мы получили цепочку из двух сертификатов в каталоге /tmp.

Но мы хотели получить выполняемые модули для платформ Linux и Windowsи и чтобы пользователи не задумывались о каких-то интерпретаторах.

Для этой цели мы воспользуемся утилитой freewrapTCLSH. С помощью этой утилиты мы сделаем выполняемые модули нашей утилиты для платформ Linux и Windows как 32-х разрядных так и 64-х. Сборку утилит можно проводить для всех платформ на любой из платформ. Извините за тавтологию. Я буду собирать на linux_x86_64 (Mageia).

Для сборки потребуется:

1. Утилита freewrapTCLSH для платформы linux_x86_64;
2. Файл freewrapTCLSH с этой утилитой для каждой платформы:
— freewrapTCLSH_linux32
— freewrapTCLSH_linux64
— freewrapTCLSH_win32
— freewrapTCLSH_win64
3. Исходный файл нашей утилиты: chainfromcert.tcl

Итак, собираемый выполняемый файл chainfromcerty_linuxx86 для платформы Linux x86:

$freewrapTCLSH chainfromcert.tcl –w freewrapTCLSH_linux32 –o chainfromcerty_linuxx86
$

Сборка утилиты для платформы Windows 64-х битного выглядит так:

$freewrapTCLSH chainfromcert.tcl –w freewrapTCLSH_win64 –o chainfromcerty_win64.exe
$

И т.д. Утилиты готовы к использованию. Все необходимое для их работы они вобрали в себя.
Аналогичным образом пишется код и на Python-е.

В ближайшие дни я думаю дополнить пакет fsb795 (а он написан на Python-е) функцией получения цепочки корневых сертификатов.

Комментарии (44)

a513
16.01.2019 20:12
#19623102
+2
У вас же есть готовые утилиты. Скажите где их можно скачать? Спасибо.
1. saipr Автор
  16.01.2019 20:15
  #19623114
  +1
  Посмотрите готовые утилиты здесь.
  1. a513
    16.01.2019 21:21
    #19623326
    Посмотрел, но скачать не могу, говорит прав нету!
    
    saipr Автор
    16.01.2019 21:22
    #19623332
    Извините. Поправили. Большое спасибо.
    
    a513
    16.01.2019 21:33
    #19623374
    +1
    Спасибо. Скачал. Проверил. Все работает.

a0fs
16.01.2019 21:42
#19623400
Кто-нибудь мне объяснить в чём смысл ИОК (PKI), если необходимо где-то как-то доставать сертификаты ЦС (CA). Им нужно доверять, а следовательно их нужно получить из доверенных источников. Меня всю дорогу умиляло, что ЦС для работы с госуслугами качается на сайте госуслуг по простому http (раньше, сейчас не знаю). Это что вообще за фигня?.. Мне нужно установить в хранилище доверенных сертификатов это. А откуда я знаю что его по дороге не подменили? Можно было бы рассылать его хеш в разных журналах для бухгалтеров и вообще писать на каждом заборе, тогда это было бы чем-то осмысленным, а так хрень.

А тут вообще скриптами, что-то, откуда-то, как-то тянут. Это каким местом относится к идентификации и аутентификации участников обмена то? Нафиг нам такое нужно?
1. saipr Автор
  17.01.2019 22:03
  #19623488
  Удостоверяющий Центр — это фактически тот же ОВД, только выдает не паспорт, а сертификат. И когда хотят проверить паспорт, то обращаются в ОВД (сейчас миграционная служба) за подтверждением, что они выдавали такой-то паспорт и он на данный момент действителен. Аналогично и с сертификатом — обращаются в УЦ за поддтверждением (в частности через списки отозванных сертификатов, службу OCSP). В простом http тоже нет криминала, если информация передается подписанной, а тем более зашифрованной. И том и другом случае ее нельзя подминить.
  
  Мне нужно установить в хранилище доверенных сертификатов это. А откуда я знаю что его по дороге не подменили?
  Он же сертификат, его нельзя подменить. Это будет либо не сертификат либо какой-то чужой сертификат. И при подписании/проверки/шифровании.дешифровании все это всплывет. И вам нужно будет все же поставить корневой сертификат вашего УЦ и всю цепочку.
  
  Можно было бы рассылать его хеш в разных журналах для бухгалтеров и вообще писать на каждом заборе, тогда это было бы чем-то осмысленным, а так хрень.
  Так это так и делается. Все о чем вы говорите, есть так или иначе в сертификате. Сертификат вещь публичная.
  
  Нафиг нам такое нужно?
  Вы просто еще не осознали всей прелести ИОК/OKI, тем более у нас она такая сегодня какая есть. А это горько. Хорошее дело десткркдитируктся. Я лично понимаю ваши эмоции. Сам каждый день, извини, плююсь на наше цифровую"экономику".
  1. firk
    17.01.2019 22:38
    #19623640
    Вы так пишете, как будто не понимаете зачем нужны корневые сертификаты. А нужны они затем, чтобы этот самый удостоверяющий центр можно было идентифицировать и отличить от поддельных удостоверяющих центров.
    
    Аналогично и с сертификатом — обращаются в УЦ за поддтверждением
    Чтобы обратиться в УЦ и знать, что это настоящий УЦ а не фейковый — вам нужно заранее иметь его сертификат. А вы только хотите его скачать.
    
    если информация передается подписанной,
    До тех пор, пока этого сертификата у вас нет, никакие подписи вы проверить надёжно не сможете.
    
    Он же сертификат, его нельзя подменить. Это будет либо не сертификат либо какой-то чужой сертификат. И при подписании/проверки/шифровании.дешифровании все это всплывет. И вам нужно будет все же поставить корневой сертификат вашего УЦ и всю цепочку.
    Если вам подсунут поддельный сертификат и будут постоянно производить MITM, то ничего не всплывёт. А в каких-то сценариях и без MITM не всплывёт.
    
    saipr Автор
    17.01.2019 22:54
    #19623698
    До тех пор, пока этого сертификата у вас нет, никакие подписи вы проверить надёжно не сможете.
    Подпись либо есть, либо нет. Другого не дано. Что такое проверить надежно вообще загадка. См. предыдущее предложениею
    
    Если вам подсунут поддельный сертификат и будут постоянно производить MITM, то ничего не всплывёт. А в каких-то сценариях и без MITM не всплывёт.
    Какой поддельный сертификат и как мне можно подсунуть? Это как в ФНС и Госуслуги, которыми мы пользуемся, кто, что-то подсунет?
    Это из какой-то потусторонней действительности.
    
    jia3ep
    17.01.2019 08:19
    #19624436
    Какой поддельный сертификат и как мне можно подсунуть?
    Нужно определиться от чего мы защищаемся используя ГОСТовые УЦ. Я смею предположить, что от западных спецслужб (от всего остального защищает PKI на западных алгоритмах). А поскольку они потенциально контролируют выпуск стандартных https сертификатов, то получать корневой ГОСТовый сертификат недоверенным способом (по западному https) по меньшей мере странно.
    
    Это из какой-то потусторонней действительности.
    Из потусторонней действительности то, что мой приватный ключ подписи налоговой декларации хранится у потенциального нарушителя (он генерируется и хранится на сайте ФНС) и доступ к нему осуществляется по обычному паролю (!) через канал связи, защищенный западными алгоритмами. Такая система «защиты» ничего, кроме недоумения не вызывает.
    
    gosha-z
    17.01.2019 08:49
    #19624492
    Чего-чего??? Если от вас ушел приватный ключ — это называется «дискредитация сертификата», о чем вы должны немедленно заявить в УЦ. Приватный ключ — он на то и приватный, что никуда дальше вас не уходит. Вы, видимо, путаете приватные и сессионные ключи…
    
    jia3ep
    17.01.2019 08:56
    #19624514
    Нет, не путаю. Посмотрите как устроена подпись документов в ФНС. www.nalog.ru/rn53/news/tax_doc_news/5750992
    
    Обратите внимание на «ключ электронной подписи хранится в «облаке» в защищенном хранилище ФНС России». Именно этот вариант работает, если у вас нет сертифицированного криптопровайдера на ПК.
    
    gosha-z
    17.01.2019 09:11
    #19624552
    Что мешает поставить сертифицированное СКЗИ?
    
    jia3ep
    17.01.2019 09:20
    #19624572
    Во-первых, рекомендуемый на сайте ФНС криптопровайдер КриптоПРО CSP стоит 2700 руб.
    Во-вторых, я бы не хотел ставить в систему ПО, которое на низком уровне вмешивается в работу ОС. Решения от вендоров ОС вдоль и поперек исследуются экспертами со всего мира, чего мы не можем сказать об отечественных (или западных небольших) разработчиках. Кто исследует их ПО?
    
    Также стоит отметить, что ПО криптопровайдера скачивается по каналам, защищенным западными алгоритмами. Так от чего мы защищаемся? )
    
    gosha-z
    17.01.2019 09:28
    #19624610
    А какое отношение шифрование имеет к проверке подлинности?
    
    saipr Автор
    17.01.2019 09:39
    #19624646
    Во-первых, рекомендуемый на сайте ФНС криптопровайдер КриптоПРО CSP стоит 2700 руб.
    Вот это и порочно. Это и навязывание и еще есть другое слово.
    Все должно быть доступно как на западе: поставил ОС, если это Windows доступны CSP. Поставил linux — доступно NSS. Firefox поставил в нем или при нем все есть. Это касается и IE и GoogleChrome и т.д.
    
    a0fs
    17.01.2019 21:52
    #19628796
    Решения от вендоров ОС вдоль и поперек исследуются экспертами со всего мира, чего мы не можем сказать об отечественных (или западных небольших) разработчиках
    
    Вы меня простите, но это утверждение со времён когда в OpenSSL, куда не просто смотрят, а целенаправленно его анализируют крутые (надеюсь самые крутые) эксперты по безопасности, нашли дыры, которым выжить помогло нечитаемость того кода, в котором они жили. Чем популярнее ПО тем больше желания у разных органов в нём оставить свои закладки… И да, органы в просвещённом западе тоже есть, и они не менее зубасты и прилипчивы чем наши.
    
    saipr Автор
    17.01.2019 22:11
    #19628864
    И да, органы в просвещённом западе тоже есть, и они не менее зубасты и прилипчивы чем наши.
    Сага о русских и немецких программистах и об OpenSSL тоже
    
    > think noone ever looked at the code as deeply as you did. Christian Hohnstadt, Programming, Translation and Testing XCA
    
    Перевод:
    
    > Я думаю, что еще никто так глубоко не заглядывал в мой код, как вы. Christian Hohnstadt, разработчик XCA
    
    saipr Автор
    17.01.2019 10:17
    #19624820
    Да есть такая уникальная возможность в ФНС. Создают какую-то электронную подпись (причем сразу и на все слчае жизни). Вообще ничего не надо, пи провайдеров, ни IE, ни Windows. Что подписываеися и как (многие говорят что ничего не подписывается, а все работает по галочке). Пользователь никак и ни на что не влияет. За него можно подписать все что угодно. Как написал a0fs:
    
    Нафиг нам такое нужно?
    
    a0fs
    17.01.2019 22:11
    #19628866
    +1
    Нужно определиться от чего мы защищаемся используя ГОСТовые УЦ. Я смею предположить, что от западных спецслужб (от всего остального защищает PKI на западных алгоритмах). А поскольку они потенциально контролируют выпуск стандартных https сертификатов, то получать корневой ГОСТовый сертификат недоверенным способом (по западному https) по меньшей мере странно.
    
    Используя ГОСТ-овский УЦ мы решаем не задачу борьбы со спецслужбами, поскольку, если у нас западное ПО, то с этими спецслужбами бороться сложно, они вполне могут иметь у нас свои закладки (надеюсь мы не будем дискутировать по вопросу о их наличии, и остановимся на том, что теоретически они там могут быть, а следовательно полностью доверять ПО мы не можем), а следовательно несколько лишено смысла. При этом я КРАЙНЕ надеюсь, что нашим разработчикам ОС (да это линукс, QNX, что-то ещё, не суть) хватило ума вложить сертификат ГУЦ в свою систему и нам получать его уже не нужно. Мы решаем другую задачу, развития собственных криптографических средств и собственной инфраструктуры. Кроме того, параноик внутри меня задаёт много неудобных вопросов основные из них: почему вывоз из США RSA был полу-шпионской историей со странными телодвижениями, а текущий шифр AES-256 которым, по слухам закрывается всё вплоть до гостайны США встраивается в процессоры и экспортируется свободно? А тот ли это шифр которым закрывают гостайну? А может есть гражданская версия шифра, с гораздо меньшим уровнем стойкости? Если мы можем создать свой шифр, имеем школу математиков и нам по силам эта задача, то мы ДОЛЖНЫ создать этот шифр любой ценой. Это как держать на своём вооружении танки выпускаемые где-то в другой стране, в нужный момент их могут просто перестать поставлять либо поставлять с недостатками, о которых узнаешь либо чудом, либо когда будет поздно.
    
    saipr Автор
    17.01.2019 22:21
    #19628892
    Вот эти все вопросы я и пытался поднять в публикации на хабре "Какими я вижу операционные системы". Привлечь внимание разработчиков ОС и т.д. Вы думаете получилось? Мне кажется нет. Хотя 60 тысяч просмотров, но некоторые комментарии просто ...
    
    При этом я КРАЙНЕ надеюсь, что нашим разработчикам ОС (да это линукс, QNX, что-то ещё, не суть) хватило ума вложить сертификат ГУЦ в свою систему и нам получать его уже не нужно.
    Нет, не хватило. Попытки обратить внимание на это, на плюхи взападном ПО, которое тиражируется в наших ОС — все пока в пустую.
    
    Мы решаем другую задачу, развития собственных криптографических средств и собственной инфраструктуры.
    Вот именно в решение этой задачи я и пытался внести свобю лепту (ниже цитата из статьи):
    
    И так, какой напрашивается вывод? Напоминаю, мы говорили про электронную подпись, про использование отечественной криптографии.
    Первое, доступ к порталам не должен зависеть от типа операционной системы и используемого криптопровайдера.
    Второе, отечественные ОС должны иметь в своем составе браузеры с поддержкой ГОСТ-ового https.
    Третье, отечественные ОС должны иметь в своем составе почтовые клиенты с поддержкой ГОСТ (подписание/шифрование).
    Четвертое, отечественные ОС должны иметь в своем составе средства электронной подписи и шифрования
    Пятое, отечественные ОС должны иметь поддержку токенов/смарткарт PKCS#11 с поддержкой российской криптографии.
    Вот если этот минимум будет реализован, то можно говорить от отечественных ОС типа Linux.
    Чувствуете как перекликается с вашими словами. Спасибо.
    
    saipr Автор
    17.01.2019 10:07
    #19624782
    Если вам подсунут поддельный сертификат
    Вместо моего личного, который я получил? И как это мне его подменят. А не подменив его, я всегда буду знать все про цепочку и ее действительность. Но крайней мере хотя в виде "на данный момент времени проверить такой-то сертификат не предоставляется возможным"
  1. a0fs
    17.01.2019 22:52
    #19623694
    В Вашем примере ОВД — это вполне себе доверенная организация, и если рядом с Вашим домом откроется нечто с надписью ОВД района Рогокопытинска, в их двери достаточно быстро (хочется верить) постучат представители полиции, причём прикладами автоматов. В ИОК всё сложнее. Сертификат я должен получить не из канала, по которому происходит взаимодействие с контрагентом. Обычно сертификаты корневых ЦС ставятся в систему, в организации они разливаются либо админами при установке серверов, либо политиками AD если мы говорим о Windows-сети. На момент начала взаимодействия у меня уже должен быть этот сертификат. После того как я его установлю в хранилище доверенных ВСЁ (совсем ВСЁ!!!), что подписано этим сертификатом будет считаться правдой. Если я иду на сайт Госуслуг, и мне через DNS спуфинг или иными способами подкладывают лажу, и я качаю от туда сертификат, ставлю его себе, дальше эти граждане могут влезть мне в любую TLS сессию если там не используется свой список доверенных сертификатов, либо не используется пининг. То есть Гугл возможно и ругнётся, если я полезу хромом. А вот залезть в сбер-онлайн теоретически смогут.
    
    Как избежать этого?
    
    Нужно получать сертификаты по HTTPS, где ресурс, на который я иду подписан сертификатом ЦС, имеющимся у меня в системе, кроме того у меня должен быть канал получения хотя бы хеша сертификата ЦС который я устанавливаю из другого места, чтобы сложнее было контролировать оба канала получения информации.
    
    Пропихнуть в доверенные сертификаты ОС и браузеров (по крайней мере распространяющихся в России и на русском языке) корневой сертификат ГУЦ
    
    Распространять сертификат ГУЦ вместе с ПО электронного документооборота, бухгалтерского ПО, ПО налоговиков, ПФРФ. Я ДОЛЖЕН! получить сертификат до того как он мне понадобится либо иметь возможность проверить то, что мне пришло на благонадёжность.
    
    Цифровая экономика хорошо. Плохо, что хорошая идея покрывается неприличным количеством бардака, причём объём этого бардака грозит сделать эту идею мало того, что бесполезной, так ещё и опасной…
    
    saipr Автор
    17.01.2019 22:57
    #19623706
    На момент начала взаимодействия у меня уже должен быть этот сертификат.
    Да вы его получаете вместе со своим сертификатом.
    А дальше читаем что такое PKI, его матаматические, организационные и законодательные основы.
    
    Плохо, что хорошая идея покрывается неприличным количеством бардака, причём объём этого бардака грозит сделать эту идею мало того, что бесполезной, так ещё и опасной…
    Так надо наводить порядок.
    
    AEP
    17.01.2019 00:48
    #19624014
    Пропихнуть в доверенные сертификаты ОС и браузеров (по крайней мере распространяющихся в России и на русском языке) корневой сертификат ГУЦ
    
    К сожалению, невозможно для браузеров, состоящих в CA/Browser Forum. Это такая организация, которая определяет правила, что можно, а что нельзя иметь в списке доверенных сертификатов по умолчанию. И вот что там написано.
    
    6.1.1.3. Subscriber Key Pair Generation.
    The CA SHALL reject a certificate request if the requested Public Key does not meet the requirements set forth in Sections 6.1.5 and 6.1.6
    
    6.1.5. Key Sizes. Большая таблица, что можно для каждого алгоритма и типа сертификата. ГОСТа там нет.
    
    6.1.6. Public Key Parameters Generation and Quality Checking. Отдельные процедуры для DSA, RSA и ECC.
    
    Так вот — ни ГОСТов, ни даже Ed25519, в этих таблицах нет, и поэтому CA, которым доверяют браузеры, не имеют права выпускать сертификаты с использованием этих алгоритмов. Let's Encrypt на это уже напоролись, community.letsencrypt.org/t/69868.
    
    a0fs
    17.01.2019 01:12
    #19624066
    Ну в этом месте ничего не мешает выпустить сертификат с самой ядрёной RSA-шкой, для работы с публичными сайтами. Это позволит иметь независимый от иностранных ЦС корень, и возможность работать с TLS, А уже с этих сайтов, с использованием TLS, получать сертификат ГУЦ, и строить на Российской криптографии закрытые разделы тех же сайтов, и весь остальной электронный документооборот. Это по крайней мере лучше, чем раздавать сертификаты по нешифрованным каналам.
    Ну или, если религия совсем запрещает работу с RSA, выпустить спецбраузер чтоли....
    
    saipr Автор
    17.01.2019 09:30
    #19624618
    Для получения корневого сертификата TLS не нужен (хотя и не помешает), сертификаты самозащищены на то они ми сертификаты (что-то подправил — уже не сертификат). Сертификат публичная вещь и шифрованные каналы не нужны.
    Ну а про российский TLS можно посмотреть здесь.
    
    stork_teadfort
    17.01.2019 11:03
    #19625032
    Коневые сертификаты самозащищены на уровне «мамой клянусь, да».
    Что мешает MITM-гаю выпустить другой корневой ГУЦа с тем же самым набором текстовых атрибутов? Чем он принципиально будет отличаться от легитимного?
    Правильно, хэшем, серийным номером и открытым ключом. И если я их не знаю из независимого канала (например, Российской газеты, лол), то как мне отличить подделку?
    
    saipr Автор
    17.01.2019 11:48
    #19625348
    Получите корневой сертификат с трех разных рабочих мест. Сравните их. Если что-то не так то идем ножками в УЦ, убеждаемся что не левый УЦ (лицензии, аккредитации, ЕГРЮЛ) и под роспись получаем сертификат. Идем на свое рабочее место и ставим. Флэшку запираем в сейф. Вроде все. Все как с паспортом.
    
    a0fs
    17.01.2019 21:44
    #19628772
    Вот мы тут и ратуем, чтобы было хотя бы второе место. А весь сертификат получать смысла нет, можно ограничится хешем.
    
    saipr Автор
    17.01.2019 22:05
    #19628850
    Пришли к консенсусу. Хорошо.

KanuTaH
17.01.2019 01:35
#19624108
Обожаю Tcl. Небольшое замечание — в Tcl == для сравнения строк в общем случае лучше не применять, потому что expr при этом может выполнять приведения типов, например, сравнение «1» == «1.0» вернёт 1, хотя это разные строки. Для сравнения именно строк лучше применять eq или string equal например.
1. saipr Автор
  17.01.2019 09:23
  #19624588
  Нашего полку прибыло! Спасибо за ценное замечание. Да, так можно случайно и впросак попасть. Но в данном случае все нормально. Еще раз спасибо.

svk28
17.01.2019 16:34
#19627352
+2
Тиклю 30 лет исполнилось, кстати!
1. saipr Автор
  17.01.2019 16:51
  #19627460
  +1
  Спасибо. Надо будет достойно отметить. Тем более и я с ним 20 лет знаком.
  1. svk28
    17.01.2019 17:15
    #19627588
    +1
    Я чуть поменьше — лет 17 )
    
    saipr Автор
    17.01.2019 17:44
    #19627768
    +1
    Нас уже трое!
1. KanuTaH
  17.01.2019 17:03
  #19627524
  +2
  Даа… Ностальгия, ностальгия. В их официальном extension repo даже есть один или два моих пакета.
  1. saipr Автор
    17.01.2019 17:43
    #19627762
    Ностальгия — Прекрасное чувство! А ссылку все же дайте.
    
    KanuTaH
    17.01.2019 17:52
    #19627832
    +2
    Ну вот как минимум один свой я нашел:
    
    core.tcl.tk/jenglish/gutter/packages/radclient.html
    
    Вторым публичным пакетом была thread-safe версия package Rrd для rrdtool, но что-то в общем списке пакетов по слову «rrd» я ее не смог найти. Видимо, я тогда ограничился тем, что моя версия этого пакета вошла в официальную поставку rrdtool.
    
    saipr Автор
    17.01.2019 18:13
    #19627920
    Спасибо. Вызывает уважение. Кто знает и пригодиться.
1. saipr Автор
  17.01.2019 18:33
  #19628022
  Продублировал новость про 30 лет на LINUX.ORG.RU
  1. KanuTaH
    17.01.2019 19:49
    #19628406
    +1
    Я смотрю, там у народа в комментариях Tcl прочно ассоциируется с Tk :) Ну, точнее, народ акцентирует внимание главным образом на Tk GUI и его недостатках (реальных или воображаемых). Про сам язык — а его концепция весьма изящна, лично я для быстрого написания небольших (да и больших, честно говоря, тоже) скриптов предпочитаю его Питону или Perl'у, не говоря уж о «традиционных» шеллах — мало кто пишет.
    
    P.S. Честно говоря, именно на Tk я даже никогда ничего и не писал :)
    
    saipr Автор
    17.01.2019 21:33
    #19628742
    Именно это я сейчас и вижу на LINUX.ORG.RU. Тонко подмечено. Все стали дизайнерами, функционал их не интересует.

Инфраструктура открытых ключей. Цепочка корневых сертификатов X509 v.3 +12

Комментарии (44)

saipr Автор

saipr Автор

saipr Автор

saipr Автор

saipr Автор

saipr Автор

saipr Автор

saipr Автор

saipr Автор

saipr Автор

saipr Автор

saipr Автор

saipr Автор

saipr Автор

saipr Автор

saipr Автор

saipr Автор

saipr Автор

saipr Автор

saipr Автор