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

    Неумолимо приближается час «Ч»: «использование схемы подписи ГОСТ Р 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

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

      А тут вообще скриптами, что-то, откуда-то, как-то тянут. Это каким местом относится к идентификации и аутентификации участников обмена то? Нафиг нам такое нужно?
        –1

        Удостоверяющий Центр — это фактически тот же ОВД, только выдает не паспорт, а сертификат. И когда хотят проверить паспорт, то обращаются в ОВД (сейчас миграционная служба) за подтверждением, что они выдавали такой-то паспорт и он на данный момент действителен. Аналогично и с сертификатом — обращаются в УЦ за поддтверждением (в частности через списки отозванных сертификатов, службу OCSP). В простом http тоже нет криминала, если информация передается подписанной, а тем более зашифрованной. И том и другом случае ее нельзя подминить.


        Мне нужно установить в хранилище доверенных сертификатов это. А откуда я знаю что его по дороге не подменили?

        Он же сертификат, его нельзя подменить. Это будет либо не сертификат либо какой-то чужой сертификат. И при подписании/проверки/шифровании.дешифровании все это всплывет. И вам нужно будет все же поставить корневой сертификат вашего УЦ и всю цепочку.


        Можно было бы рассылать его хеш в разных журналах для бухгалтеров и вообще писать на каждом заборе, тогда это было бы чем-то осмысленным, а так хрень.

        Так это так и делается. Все о чем вы говорите, есть так или иначе в сертификате. Сертификат вещь публичная.


        Нафиг нам такое нужно?

        Вы просто еще не осознали всей прелести ИОК/OKI, тем более у нас она такая сегодня какая есть. А это горько. Хорошее дело десткркдитируктся. Я лично понимаю ваши эмоции. Сам каждый день, извини, плююсь на наше цифровую"экономику".

          +3

          Вы так пишете, как будто не понимаете зачем нужны корневые сертификаты. А нужны они затем, чтобы этот самый удостоверяющий центр можно было идентифицировать и отличить от поддельных удостоверяющих центров.


          Аналогично и с сертификатом — обращаются в УЦ за поддтверждением

          Чтобы обратиться в УЦ и знать, что это настоящий УЦ а не фейковый — вам нужно заранее иметь его сертификат. А вы только хотите его скачать.


          если информация передается подписанной,

          До тех пор, пока этого сертификата у вас нет, никакие подписи вы проверить надёжно не сможете.


          Он же сертификат, его нельзя подменить. Это будет либо не сертификат либо какой-то чужой сертификат. И при подписании/проверки/шифровании.дешифровании все это всплывет. И вам нужно будет все же поставить корневой сертификат вашего УЦ и всю цепочку.

          Если вам подсунут поддельный сертификат и будут постоянно производить MITM, то ничего не всплывёт. А в каких-то сценариях и без MITM не всплывёт.

            –1
            До тех пор, пока этого сертификата у вас нет, никакие подписи вы проверить надёжно не сможете.

            Подпись либо есть, либо нет. Другого не дано. Что такое проверить надежно вообще загадка. См. предыдущее предложениею


            Если вам подсунут поддельный сертификат и будут постоянно производить MITM, то ничего не всплывёт. А в каких-то сценариях и без MITM не всплывёт.

            Какой поддельный сертификат и как мне можно подсунуть? Это как в ФНС и Госуслуги, которыми мы пользуемся, кто, что-то подсунет?
            Это из какой-то потусторонней действительности.

              0
              Какой поддельный сертификат и как мне можно подсунуть?
              Нужно определиться от чего мы защищаемся используя ГОСТовые УЦ. Я смею предположить, что от западных спецслужб (от всего остального защищает PKI на западных алгоритмах). А поскольку они потенциально контролируют выпуск стандартных https сертификатов, то получать корневой ГОСТовый сертификат недоверенным способом (по западному https) по меньшей мере странно.

              Это из какой-то потусторонней действительности.
              Из потусторонней действительности то, что мой приватный ключ подписи налоговой декларации хранится у потенциального нарушителя (он генерируется и хранится на сайте ФНС) и доступ к нему осуществляется по обычному паролю (!) через канал связи, защищенный западными алгоритмами. Такая система «защиты» ничего, кроме недоумения не вызывает.
                0
                Чего-чего??? Если от вас ушел приватный ключ — это называется «дискредитация сертификата», о чем вы должны немедленно заявить в УЦ. Приватный ключ — он на то и приватный, что никуда дальше вас не уходит. Вы, видимо, путаете приватные и сессионные ключи…
                  +1
                  Нет, не путаю. Посмотрите как устроена подпись документов в ФНС. www.nalog.ru/rn53/news/tax_doc_news/5750992

                  Обратите внимание на «ключ электронной подписи хранится в «облаке» в защищенном хранилище ФНС России». Именно этот вариант работает, если у вас нет сертифицированного криптопровайдера на ПК.
                    0
                    Что мешает поставить сертифицированное СКЗИ?
                      +1
                      Во-первых, рекомендуемый на сайте ФНС криптопровайдер КриптоПРО CSP стоит 2700 руб.
                      Во-вторых, я бы не хотел ставить в систему ПО, которое на низком уровне вмешивается в работу ОС. Решения от вендоров ОС вдоль и поперек исследуются экспертами со всего мира, чего мы не можем сказать об отечественных (или западных небольших) разработчиках. Кто исследует их ПО?

                      Также стоит отметить, что ПО криптопровайдера скачивается по каналам, защищенным западными алгоритмами. Так от чего мы защищаемся? )
                        0
                        А какое отношение шифрование имеет к проверке подлинности?
                          0
                          Во-первых, рекомендуемый на сайте ФНС криптопровайдер КриптоПРО CSP стоит 2700 руб.

                          Вот это и порочно. Это и навязывание и еще есть другое слово.
                          Все должно быть доступно как на западе: поставил ОС, если это Windows доступны CSP. Поставил linux — доступно NSS. Firefox поставил в нем или при нем все есть. Это касается и IE и GoogleChrome и т.д.

                          0
                          Решения от вендоров ОС вдоль и поперек исследуются экспертами со всего мира, чего мы не можем сказать об отечественных (или западных небольших) разработчиках

                          Вы меня простите, но это утверждение со времён когда в OpenSSL, куда не просто смотрят, а целенаправленно его анализируют крутые (надеюсь самые крутые) эксперты по безопасности, нашли дыры, которым выжить помогло нечитаемость того кода, в котором они жили. Чем популярнее ПО тем больше желания у разных органов в нём оставить свои закладки… И да, органы в просвещённом западе тоже есть, и они не менее зубасты и прилипчивы чем наши.
                        0

                        Да есть такая уникальная возможность в ФНС. Создают какую-то электронную подпись (причем сразу и на все слчае жизни). Вообще ничего не надо, пи провайдеров, ни IE, ни Windows. Что подписываеися и как (многие говорят что ничего не подписывается, а все работает по галочке). Пользователь никак и ни на что не влияет. За него можно подписать все что угодно. Как написал a0fs:


                        Нафиг нам такое нужно?
                      +1
                      Нужно определиться от чего мы защищаемся используя ГОСТовые УЦ. Я смею предположить, что от западных спецслужб (от всего остального защищает PKI на западных алгоритмах). А поскольку они потенциально контролируют выпуск стандартных https сертификатов, то получать корневой ГОСТовый сертификат недоверенным способом (по западному https) по меньшей мере странно.

                      Используя ГОСТ-овский УЦ мы решаем не задачу борьбы со спецслужбами, поскольку, если у нас западное ПО, то с этими спецслужбами бороться сложно, они вполне могут иметь у нас свои закладки (надеюсь мы не будем дискутировать по вопросу о их наличии, и остановимся на том, что теоретически они там могут быть, а следовательно полностью доверять ПО мы не можем), а следовательно несколько лишено смысла. При этом я КРАЙНЕ надеюсь, что нашим разработчикам ОС (да это линукс, QNX, что-то ещё, не суть) хватило ума вложить сертификат ГУЦ в свою систему и нам получать его уже не нужно. Мы решаем другую задачу, развития собственных криптографических средств и собственной инфраструктуры. Кроме того, параноик внутри меня задаёт много неудобных вопросов основные из них: почему вывоз из США RSA был полу-шпионской историей со странными телодвижениями, а текущий шифр AES-256 которым, по слухам закрывается всё вплоть до гостайны США встраивается в процессоры и экспортируется свободно? А тот ли это шифр которым закрывают гостайну? А может есть гражданская версия шифра, с гораздо меньшим уровнем стойкости? Если мы можем создать свой шифр, имеем школу математиков и нам по силам эта задача, то мы ДОЛЖНЫ создать этот шифр любой ценой. Это как держать на своём вооружении танки выпускаемые где-то в другой стране, в нужный момент их могут просто перестать поставлять либо поставлять с недостатками, о которых узнаешь либо чудом, либо когда будет поздно.
                        0

                        Вот эти все вопросы я и пытался поднять в публикации на хабре "Какими я вижу операционные системы". Привлечь внимание разработчиков ОС и т.д. Вы думаете получилось? Мне кажется нет. Хотя 60 тысяч просмотров, но некоторые комментарии просто ...


                        При этом я КРАЙНЕ надеюсь, что нашим разработчикам ОС (да это линукс, QNX, что-то ещё, не суть) хватило ума вложить сертификат ГУЦ в свою систему и нам получать его уже не нужно.

                        Нет, не хватило. Попытки обратить внимание на это, на плюхи взападном ПО, которое тиражируется в наших ОС — все пока в пустую.


                        Мы решаем другую задачу, развития собственных криптографических средств и собственной инфраструктуры.

                        Вот именно в решение этой задачи я и пытался внести свобю лепту (ниже цитата из статьи):


                        И так, какой напрашивается вывод? Напоминаю, мы говорили про электронную подпись, про использование отечественной криптографии.
                        Первое, доступ к порталам не должен зависеть от типа операционной системы и используемого криптопровайдера.
                        Второе, отечественные ОС должны иметь в своем составе браузеры с поддержкой ГОСТ-ового https.
                        Третье, отечественные ОС должны иметь в своем составе почтовые клиенты с поддержкой ГОСТ (подписание/шифрование).
                        Четвертое, отечественные ОС должны иметь в своем составе средства электронной подписи и шифрования
                        Пятое, отечественные ОС должны иметь поддержку токенов/смарткарт PKCS#11 с поддержкой российской криптографии.
                        Вот если этот минимум будет реализован, то можно говорить от отечественных ОС типа Linux.

                        Чувствуете как перекликается с вашими словами. Спасибо.

                    0
                    Если вам подсунут поддельный сертификат

                    Вместо моего личного, который я получил? И как это мне его подменят. А не подменив его, я всегда буду знать все про цепочку и ее действительность. Но крайней мере хотя в виде "на данный момент времени проверить такой-то сертификат не предоставляется возможным"

                    +1
                    В Вашем примере ОВД — это вполне себе доверенная организация, и если рядом с Вашим домом откроется нечто с надписью ОВД района Рогокопытинска, в их двери достаточно быстро (хочется верить) постучат представители полиции, причём прикладами автоматов. В ИОК всё сложнее. Сертификат я должен получить не из канала, по которому происходит взаимодействие с контрагентом. Обычно сертификаты корневых ЦС ставятся в систему, в организации они разливаются либо админами при установке серверов, либо политиками AD если мы говорим о Windows-сети. На момент начала взаимодействия у меня уже должен быть этот сертификат. После того как я его установлю в хранилище доверенных ВСЁ (совсем ВСЁ!!!), что подписано этим сертификатом будет считаться правдой. Если я иду на сайт Госуслуг, и мне через DNS спуфинг или иными способами подкладывают лажу, и я качаю от туда сертификат, ставлю его себе, дальше эти граждане могут влезть мне в любую TLS сессию если там не используется свой список доверенных сертификатов, либо не используется пининг. То есть Гугл возможно и ругнётся, если я полезу хромом. А вот залезть в сбер-онлайн теоретически смогут.

                    Как избежать этого?
                    1. Нужно получать сертификаты по HTTPS, где ресурс, на который я иду подписан сертификатом ЦС, имеющимся у меня в системе, кроме того у меня должен быть канал получения хотя бы хеша сертификата ЦС который я устанавливаю из другого места, чтобы сложнее было контролировать оба канала получения информации.
                    2. Пропихнуть в доверенные сертификаты ОС и браузеров (по крайней мере распространяющихся в России и на русском языке) корневой сертификат ГУЦ
                    3. Распространять сертификат ГУЦ вместе с ПО электронного документооборота, бухгалтерского ПО, ПО налоговиков, ПФРФ. Я ДОЛЖЕН! получить сертификат до того как он мне понадобится либо иметь возможность проверить то, что мне пришло на благонадёжность.

                    Цифровая экономика хорошо. Плохо, что хорошая идея покрывается неприличным количеством бардака, причём объём этого бардака грозит сделать эту идею мало того, что бесполезной, так ещё и опасной…
                      0
                      На момент начала взаимодействия у меня уже должен быть этот сертификат.

                      Да вы его получаете вместе со своим сертификатом.
                      А дальше читаем что такое PKI, его матаматические, организационные и законодательные основы.


                      Плохо, что хорошая идея покрывается неприличным количеством бардака, причём объём этого бардака грозит сделать эту идею мало того, что бесполезной, так ещё и опасной…

                      Так надо наводить порядок.

                        +1
                        Пропихнуть в доверенные сертификаты ОС и браузеров (по крайней мере распространяющихся в России и на русском языке) корневой сертификат ГУЦ


                        К сожалению, невозможно для браузеров, состоящих в 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.
                          0

                          Ну в этом месте ничего не мешает выпустить сертификат с самой ядрёной RSA-шкой, для работы с публичными сайтами. Это позволит иметь независимый от иностранных ЦС корень, и возможность работать с TLS, А уже с этих сайтов, с использованием TLS, получать сертификат ГУЦ, и строить на Российской криптографии закрытые разделы тех же сайтов, и весь остальной электронный документооборот. Это по крайней мере лучше, чем раздавать сертификаты по нешифрованным каналам.
                          Ну или, если религия совсем запрещает работу с RSA, выпустить спецбраузер чтоли....

                    +3
                    Обожаю Tcl. Небольшое замечание — в Tcl == для сравнения строк в общем случае лучше не применять, потому что expr при этом может выполнять приведения типов, например, сравнение «1» == «1.0» вернёт 1, хотя это разные строки. Для сравнения именно строк лучше применять eq или string equal например.
                      +1

                      Нашего полку прибыло! Спасибо за ценное замечание. Да, так можно случайно и впросак попасть. Но в данном случае все нормально. Еще раз спасибо.

                      +2
                      Тиклю 30 лет исполнилось, кстати!
                        +1

                        Спасибо. Надо будет достойно отметить. Тем более и я с ним 20 лет знаком.

                          +1
                          Я чуть поменьше — лет 17 )
                            +2

                            Нас уже трое!

                          +2
                          Даа… Ностальгия, ностальгия. В их официальном extension repo даже есть один или два моих пакета.
                            0

                            Ностальгия — Прекрасное чувство! А ссылку все же дайте.

                              +3
                              Ну вот как минимум один свой я нашел:

                              core.tcl.tk/jenglish/gutter/packages/radclient.html

                              Вторым публичным пакетом была thread-safe версия package Rrd для rrdtool, но что-то в общем списке пакетов по слову «rrd» я ее не смог найти. Видимо, я тогда ограничился тем, что моя версия этого пакета вошла в официальную поставку rrdtool.
                                0

                                Спасибо. Вызывает уважение. Кто знает и пригодиться.

                            0

                            Продублировал новость про 30 лет на LINUX.ORG.RU

                              +1
                              Я смотрю, там у народа в комментариях Tcl прочно ассоциируется с Tk :) Ну, точнее, народ акцентирует внимание главным образом на Tk GUI и его недостатках (реальных или воображаемых). Про сам язык — а его концепция весьма изящна, лично я для быстрого написания небольших (да и больших, честно говоря, тоже) скриптов предпочитаю его Питону или Perl'у, не говоря уж о «традиционных» шеллах — мало кто пишет.

                              P.S. Честно говоря, именно на Tk я даже никогда ничего и не писал :)
                                0

                                Именно это я сейчас и вижу на LINUX.ORG.RU. Тонко подмечено. Все стали дизайнерами, функционал их не интересует.

                          Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                          Самое читаемое