diff options
Diffstat (limited to 'pages/features')
| -rw-r--r-- | pages/features/cryptography/en.text | 4 | ||||
| -rw-r--r-- | pages/features/cryptography/pt.text | 2 | ||||
| -rw-r--r-- | pages/features/cryptography/ru.text | 137 | ||||
| -rw-r--r-- | pages/features/email/ru.text | 158 |
4 files changed, 147 insertions, 154 deletions
diff --git a/pages/features/cryptography/en.text b/pages/features/cryptography/en.text index 30b22b4..7cc32f4 100644 --- a/pages/features/cryptography/en.text +++ b/pages/features/cryptography/en.text @@ -18,9 +18,7 @@ A second limitation is with the web application. It also uses SRP, but the SRP j We have three plans for the future to overcome these potential problems: # Allow the use of an additional long random key that is required as part of the authentication process (optionally). For example, each device a user has Bitmask installed on could have a "device key" and the user would need to authorize these device keys before they could run Bitmask on that new device. - # We also plan to include with Bitmask a bloom filter of the top 10,000 most commonly used passwords. By some accounts, 98.8% of all users pick a password in the top 10,000. A bloom filter of these passwords is relatively small, and we can simply forbid the user from selecting any of these (albeit with some false positives). - # Allow providers to forbid authentication via the web application. Authentication would happen via the Bitmask app, which would then load the website with the session token it obtained. This way, the critical SRP authentication code is never loaded from the provider. For more information, see: @@ -134,7 +132,7 @@ h2. Secure Updates - TUF The secure updates are done using [[TUF => http://theupdateframework.com/]], they use OpenSSL 4096 RSA keys with pyCrypto. There is three keys involved in the update process (root, targets and timestamp). -* The root key is used to certify the rest of the keys that lives in an offline storage and only gets used once per year to update the cerification or in case of rotation of another other key. +* The root key is used to certify the rest of the keys that lives in an offline storage and only gets used once per year to update the certification or in case of rotation of another other key. * The targets key is used to sign all the updates. This key is in the hands of the release manager and used on every release. * The timestamp key is used to sing a timestamp file every day, this file is used by the client to prevent an adversary from replaying an out-of-date updates. This key lives online in the platform servers. diff --git a/pages/features/cryptography/pt.text b/pages/features/cryptography/pt.text index 75abd4b..f532879 100644 --- a/pages/features/cryptography/pt.text +++ b/pages/features/cryptography/pt.text @@ -18,9 +18,7 @@ Uma segunda limitação tem a ver com a aplicação web. Ela também usa SRS, ma Temos três planos para futuramente superar esses problemas potenciais: # Permitir o uso de uma chave longa e aleatória adicional que seja requerida como parte do processo de autenticação (opcionalmente). Por exemplo, cada dispositivo que um usuário tenha o Bitmask instalado poderia ter uma "chave de dispositivo" e o usuário precisaria autorizar essas chaves de dispositivo antes que ele rodasse o Bitmask em um novo dispositivo. - # Também planejamos incluir com o Bitmask um filtro de _bloom_ das 10.000 senhas mais comumente usadas. Segundo algumas pesquisas, 98,8% de todos os usuários escolhem uma senha entre essas 10.000. Um filtro de _bloom_ é relativamente pequeno e podemos simplesmente proibir que o usuário selecione qualquer uma dessas senhas (embora com alguns falso positivos). - # Permitir que os provedores proibam autenticação via aplicação web. A autenticação deveria acontecer pelo aplicativo do Bitmask que, em seguida, carregaria o website com um token de seção obtido. Desta forma, o código crítico de autenticação da SRS nunca é carregado do provedor. Para mais informações, ver: diff --git a/pages/features/cryptography/ru.text b/pages/features/cryptography/ru.text index 85b22c1..3c4b419 100644 --- a/pages/features/cryptography/ru.text +++ b/pages/features/cryptography/ru.text @@ -1,153 +1,150 @@ @title = "Подробности криптографии Bitmask" @nav_title = "Подробности криптографии" -You asked for encryption details, you get encryption details. Here we try to document all the crypto used by Bitmask, and some of the thinking behind these decisions. For more details, [[inspect the source => https://leap.se/git]] or browse our [[technical documentation => https://leap.se/docs]]. +Вы просили подробную информацию о шифровании - вы получите подробную информацию о шифровании. Здесь мы попытаемся задокументировать всю криптографию, используемую Bitmask, а также некоторые мысли, которые стоят за этими решениями. Для более подробной информации [[изучайте исходный код => https://leap.se/git]] или просмотрите нашу [[техническую документацию => https://leap.se/docs]]. -h2. Authentication - Secure Remote Password +h2. Аутентификация - парольная аутентификация (SRP) -Bitmask uses Secure Remote Password (SRP) to authenticate with a service provider. SRP is a type of zero-knowledge-proof for authentication via username and password that does not give the server a copy of the actual password. Typically, password systems work by sending a cleartext copy of the password to the server, which then hashes this password and saves the hash. With SRP, the client and server negotiate a "password verifier" after several round trips. The server never has access to the cleartext of the password. +Bitmask использует парольную аутентификацию (Secure Remote Password, SRP) для проверки подлинности сервис-провайдера. SRP - это вид доказательства с нулевым разглашением для аутентификации посредством имени пользователя и пароля, которая не дает серверу копию действительного пароля. Как правило, системы паролей работают путем отправки копии пароля в незашифрованном виде серверу, который затем хеширует этот пароль и сохраняет хеш. Благодаря SRP, клиент и сервер договариваются о "верификаторе пароля" после нескольких проходов "туда-обратно". У сервера никогда нет доступа к незашифрованному паролю. -One additional benefit of SRP is that both parties authenticate each other. With traditional hashed passwords, the server can say that the password was correct, even if it has no idea what the real password is. With SRP, the user authenticates with the server, but the server also authenticates with the user. +Одним из дополнительных преимуществ SRP является то, что обе стороны аутентифицируют друг друга. Для традиционных захешированных паролей сервер может сказать, что пароль правильный, даже если он не имеет ни малейшего понятия какой настоящий пароль. Благодаря SRP, пользователь аутентифицируется сервером, но сервер также аутентифицируется пользователем. -Currently we use 1024-bit discrete-log parameters. We are exploring increasing this to 2048-bit. +В настоящее время мы используем 1024-битные параметры дискретного логарифма. Мы изучаем их увеличение до 2048-битных. -There are some limitations with SRP. A compromised or nefarious provider can attempt to brute force crack a password by trying millions of combinations, just like with normal hashed passwords. For this reason, it is still important to pick a strong password. In practice, however, users are horrible at picking strong passwords. +Для SRP существуют некоторые ограничения. Скомпрометированный или бесчестный провайдер может попытаться грубой силой взломать пароль, пробуя миллионы комбинаций, точно так же как с обычными захешированными паролями. По этой причине, по-прежнему важно выбирать надежный пароль. На практике, однако, пользователи ужасно выбирают надежные пароли. -A second limitation is with the web application. It also uses SRP, but the SRP javascript code is loaded from the provider. If the provider is compromised or nefarious, they could load some javascript to capture the user's password. +Второе ограничение связано с веб-приложением. Оно также использует SRP, но javascript-код SRP загружается от провайдера. Если провайдер скомпрометированный или бесчестный, он может загрузить некоторый javascript-код, чтобы захватить пароль пользователя. -We have three plans for the future to overcome these potential problems: +У нас есть три плана на будущее, чтобы преодолеть эти потенциальные проблемы: -# Allow the use of an additional long random key that is required as part of the authentication process (optionally). For example, each device a user has Bitmask installed on could have a "device key" and the user would need to authorize these device keys before they could run Bitmask on that new device. +# Разрешить использование дополнительного длительного случайного ключа, который используется как часть процесса аутентификации (необязательно). Например, каждое устройство, на котором установлен Bitmask, могло бы иметь "ключ устройства", и пользователь должен был бы авторизовать эти ключи устройства, прежде чем они могли бы запускать Bitmask на этом новом устройстве. +# Мы также планируем включить в Bitmask фильтр Блума 10,000 наиболее часто используемых паролей. По некоторым данным, 98,8% всех пользователей выбирают пароль из этих 10,000. Фильтр Блума этих паролей является относительно небольшим, и мы можем просто запретить пользователю выбирать любой из них (хотя и с некоторыми ложными срабатываниями). +# Разрешить провайдерам запрещать аутентификацию через веб-приложения. Аутентификация будет происходить посредством приложения Bitmask, которое затем загрузило бы на веб-сайт с помощью сеансового токена, который оно получило. Таким образом, критический код аутентификации SRP никогда не будет загружаться от провайдера. -# We also plan to include with Bitmask a bloom filter of the top 10,000 most commonly used passwords. By some accounts, 98.8% of all users pick a password in the top 10,000. A bloom filter of these passwords is relatively small, and we can simply forbid the user from selecting any of these (albeit with some false positives). - -# Allow providers to forbid authentication via the web application. Authentication would happen via the Bitmask app, which would then load the website with the session token it obtained. This way, the critical SRP authentication code is never loaded from the provider. - -For more information, see: +Для получения дополнительной информации смотрите: * http://srp.stanford.edu * https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol * https://xato.net/passwords/more-top-worst-passwords -h2. Transport - TLS +h2. Транспорт - TLS -The Bitmask client frequently makes various connections using TLS to the provider. For example, to check to see if there is an update to the list of VPN gateways. +Клиент Bitmask часто делает различные соединения с провайдером, используя TLS. Например, чтобы проверить есть ли обновление списка VPN-шлюзов. -When a service provider is first added by Bitmask, the CA certificate from the provider is downloaded via a normal TLS connection authenticated using existing x.509 CA system. This is the only moment that Bitmask relies on the CA system. +Когда сервис-провайдер впервые добавляется Bitmask, сертификат центра сертификации от провайдера загружается с помощью обычного TLS-соединения, аутентифицированного с помощью существующей системы сертификации X.509. Это единственный момент, когда Bitmask полагается на систему сертификации. -All subsequent connections with that provider use the provider-specific CA to authenticate the TLS connection. Essentially, this is a form of certificate pinning and TOFU. In order for an outside attacker to impersonate a provider, they would need to present a false x.509 server certificate authenticated by a Certificate Authority, and then intercept and rewrite all subsequent traffic between the Bitmask client and provider. +Все последующие соединения с тем провайдером используют центр сертификации конкретно для этого провайдера для проверки подлинности TLS-соединения. По сути, это форма пиннинга сертификатов и TOFU. Для того, чтобы внешнему злоумышленнику выдать себя за провайдера, он должен предоставить ложный сертификата сервера X.509, аутентифицированный центром сертификации, а затем перехватить и переписать весь последующий трафик между клиентом Bitmask и провайдером. -If a provider has been pre-seeded with the Bitmask application, then the fingerprint of the provider-specific CA certificate is known in advance. In these cases, the x.509 CA system is never relied upon. +Если провайдер был предварительно установлен приложением Bitmask, то отпечаток сертификата центра сертификации для этого провайдера известен заранее. В подобных случаях нет нужды когда-либо полагаться на систему сертификации X.509. -The provider-specific CA certificates use 4096 bit RSA with SHA256 digest, by default. The server certificates use 4096 bit RSA with SHA256 digest, by default. These defaults are easily changed. +По умолчанию сертификат центра сертификации для конкретного провайдера использует 4096-битный RSA и SHA256, сертификаты сервера используют 4096-битный RSA и SHA256. Эти значения по умолчанию можно легко изменить. -All TLS connections use PFS ciphers. +Все TLS-соединения используют шифры PFS. -h2. Storage - Soledad +h2. Хранение - Soledad -The Bitmask application stores its data in [[Soledad => https://leap.se/soledad]], which handles encrypting this data, securely backing it up, and synchronizing it among a user's devices. In Soledad, local storage uses symmetric block encryption of the entire database using a single key. For data stored remotely, each individual document is separately encrypted using a key unique to that document. +Приложение Bitmask хранит свои данные в [[Soledad => https://leap.se/soledad]], который занимается шифрованием этих данных, надежно делает их резервные копии и синхронизирует их между устройствами пользователя. В Soledad локальное хранилище использует симметричное блочное шифрование всей базы данных с использованием единственного ключа. Для данных, хранящихся удаленно, каждый отдельный документ отдельно шифруется с использованием ключа, уникального для этого документа. -Both local storage and remote storage keys are derived from a master "storage secret." This long random storage secret is stored locally on disk, protected by symmetric encryption using a key derived from the user's password (scrypt is used as the key derivation function). +Оба ключа для локального и удаленного хранилищ получаются из главного "секретного значения хранилища". Это длинное случайное секретное значение хранилища хранится на диске локально, защищенное симметричным шифрованием с помощью ключа, полученного из пароля пользователя (scrypt используется в качестве функции формирования ключа). -Currently, our scrypt parameters are: +На данный момент параметры scrypt такие: -bc. N (CPU/memory cost parameter) = 2^14 = 16384 -p (paralelization parameter) = 1 -r (length of block mixed by SMix()) = 8 -dkLen (length of derived key) = 32 bytes = 256 bits +bc. N (параметр стоимости соотношения время/память) = 2^14 = 16384 +p (степень параллельности) = 1 +r (длина блока, перемешиваемого SMix()) = 8 +dkLen (длина выходного ключа) = 32 байта = 256 бит -We are considering using a larger N. +Мы рассматриваем использование большего значения для N. -*Local storage* +*Локальное хранение* -p((. The block-encrypted local SQLite database uses @AES-256-CBC@ using the first 256 bits of [@storage_secret@]. See https://github.com/kalikaneko/python-u1dbcipher and http://sqlcipher.net. +p((. Локальная база данных SQLite с блочным шифрованием использует @AES-256-CBC@, используя первые 256 бит [@storage_secret@]. Смотрите https://github.com/kalikaneko/python-u1dbcipher и http://sqlcipher.net. -*Remote storage* +*Удаленное хранение* -p((. Per-document encryption of documents stored remotely uses symmetric encryption with AES-256-CTR or XSalsa20 cipher using 256 bit keys. The library pycryptopp is used for this. The key and MAC used to encrypt each individual document are derived as follows: +p((. Подокументное шифрование документов, хранящихся удаленно, использует симметричное шифрование с AES-256-CTR или шифр XSalsa20, использующий 256-битные ключи. Для этого используется библиотека pycryptopp. Ключ и MAC, используемые для шифрования каждого отдельного документа, получаются следующим образом: <pre style="margin-left: 2em"> -storage_secret_a = first 256 bits of storage secret -storage_secret_b = everything after first 256 bits of storage secret +storage_secret_a = первые 256 бит секретного значения хранилища +storage_secret_b = все после первых 256 битов секретного значения хранилища document_key = hmac(document_id, storage_secret_b) document_mac = hmac(document_id | document_revision | iv | ciphertext, hmac(document_id, storage_secret_a) </pre> -p((. Every document has its own key. The [@document_revision@] in the document MAC prevents a rollback to an old version of the document. HMAC uses SHA256. +p((. Каждый документ имеет свой собственный ключ. [@document_revision@] в MAC документа предотвращает откат к старой версии документа. HMAC использует SHA256. -p((. Some documents in a user's remote data store are added by the provider, such as in the case of new incoming email. These documents use asymmetric encryption, with each document encrypted using the user's OpenPGP public key. The library we use for this is [[Isis's fork of python-gnupg => https://github.com/isislovecruft/python-gnupg]]. These documents are only temporarily stored this way: as soon as the client sees them, they get unencrypted and re-encrypted using the other methods. +p((. Некоторые документы в удаленном хранилище данных пользователя добавляются провайдером, например, в случае нового входящего сообщения электронной почты. Эти документы используют асимметричное шифрование, с каждым документом, зашифрованным с использованием пользовательского открытого OpenPGP-ключа. Библиотекой, которую мы используем для этого, является [[форк Айсис python-gnupg => https://github.com/isislovecruft/python-gnupg]]. Эти документы лишь временно хранятся пободным образом: как только клиент увидит их, они остаются в незашифрованном виде и повторно шифруются с использованием других методов. -*Transport* +*Транспорт* -p((. TLS, as above. Soon to be CurveZMQ. +p((. TLS, как описано выше. Скоро будет CurveZMQ. -h2. Encrypted Tunnel - OpenVPN +h2. Зашифрованный туннель - OpenVPN -OpenVPN has three settings that control what ciphers it uses (there is a fourth, @--tls-auth@, but we cannot use this in a public multi-user environment). Every provider can easily choose whatever options they want for these. Below are the current defaults that come with the leap_platform. +OpenVPN имеет три параметра, которые управляют тем, какие шифры он использует (есть и четвертый, @--tls-auth@, но мы не можем его использовать в публичном многопользовательском окружении). Каждый провайдер может легко выбрать любые опции по своему желанию. Ниже приведены текущие значения по умолчанию, которые идут с leap_platform. *tls-cipher* -p((. The @--tls-cipher@ option governs the session authentication process of OpenVPN. If this is compromised, you could be communicating with a MiTM attacker. The TLS part of OpenVPN authenticates the server and client with each other, and negotiates the random material used in the packet authentication digest and the packet encryption. +p((. Параметр @--tls-cipher@ определяет процесс аутентификации сеанса OpenVPN. Если он будет скомпрометирован, то вашу коммуникацию сможет прослушивать злоумышленник с помощью атаки посредника. TLS часть OpenVPN аутентифицирует сервер и клиент друг с другом, и согласовывает случайное значение, используемое в значении пакетной аутентификации и пакетном шифровании. -p((. Instead of allowing many options, Bitmask only supports a single cipher (to prevent rollback attacks). +p((. Вместо того, чтобы позволять множество вариантов, Bitmask поддерживает только один шифр (для предотвращения атаки отката). -p((. For the moment, we have chosen @DHE-RSA-AES128-SHA@. The most important thing is to choose a cipher that supports PFS, as all the @DHE@ ciphers do. +p((. На данный момент, мы выбрали @DHE-RSA-AES128-SHA@. Самое главное заключается в выборе шифра, который поддерживает PFS, как это делают все шифры @DHE@. -p((. We have chosen @AES-128@ because there are known weaknesses with the @AES-192@ and @AES-256@ key schedules. There is no known weakness to brute force attacks against full 14 round AES-256, but weakness of AES-256 using other round counts is sufficient to recommend AES-128 over AES-256 generally. For more information, see Bruce Scheier's post [[ -Another New AES Attack => https://www.schneier.com/blog/archives/2009/07/another_new_aes.html]]. +p((. Мы выбрали @AES-128@ потому что известны слабости алгоритмов смены ключей @AES-192@ и @AES-256@. Неизвестны слабости к атакам прямого перебора на полный 14-раундный AES-256, однако слабости AES-256, использующего другие числа раундов, достаточно, чтобы рекомендовать AES-128 вместо AES-256 в целом. Для получения более подробной информации смотрите статью Брюса Шнайера [[Еще одна новая атака на AES => https://www.schneier.com/blog/archives/2009/07/another_new_aes.html]]. -p((. We would prefer to use ECC over RSA, and plan to eventually. It is a bit more complicated and involves changes to our TLS code in many places (recompiling openvpn, and changing certificate generation libraries used by sysadmins and the provider API). +p((. Мы бы предпочли использовать ECC вместо RSA, и в конце концов планируем это сделать. Это немного сложнее и включает в себя изменения в нашем коде TLS во многих местах (перекомпиляции OpenVPN и изменение библиотек генерации сертификатов, используемых системными администраторами и API провайдеров). -p((. The current default for client and server x.509 certificates used by OpenVPN is 2048 bit RSA and 4096 bit RSA (respectively) with SHA256 digest. This is also easily configurable by the provider (to see all the options, run @leap inspect provider.json@). +p((. Текущий стандарт для клиентских и серверных сертификатов x.509, используемых OpenVPN, является 2048-битный RSA и 4096-битный RSA (соответственно) с SHA256. Они также легко настраиваются провайдером (чтобы увидеть все варианты, запустите @leap inspect provider.json@). *auth* -p((. The @--auth@ option determines what hashing digest is used to to authenticate each packet of traffic using HMAC. +p((. Параметр @--auth@ определяет какое хеш-значение используется для аутентификации каждого пакета трафика с помощью HMAC. -p((. We have chosen to keep the @SHA1@ the default digest rather than go with @SHA256@. If an attacker can break a SHA1 HMAC on each packet in real time, you have bigger problems than your VPN. +p((. Мы решили оставить по умолчанию @SHA1@ вместо @SHA256@. Если злоумышленник может нарушать SHA1 HMAC на каждом пакете в режиме реального времени, у вас проблемы больше, нежели только с VPN. *cipher* -p((. The @--cipher@ option determines how actual traffic packets are encrypted. We have chosen @AES-128-CBC@. +p((. Параметр @--cipher@ определяет как шифруются действительные пакеты трафика. Мы выбрали @AES-128-CBC@. -p((. The OpenVPN default is probably actually better than AES-128, since it's Blowfish. We have chosen AES-128 because the TLS cipher is already relying on AES-128. We would normally prefer cipher mode OFB over CBC, but the OpenVPN manual says that "CBC is recommended and CFB and OFB should be considered advanced modes". +p((. Значение этого параметра OpenVPN по умолчанию, вероятно, на самом деле лучше, чем AES-128, так как это Blowfish. Мы выбрали AES-128, потому что шифр TLS уже полагается на AES-128. Мы, как правило, предпочитаем режим шифра OFB вместо CBC, однако в руководстве по OpenVPN говорится, что "рекомендуется CBC, а CFB и OFB следует рассматривать как расширенные режимы". h3. obfsproxy -Obfsproxy is optionally used to make VPN traffic not appear as VPN traffic to someone who is monitoring the network. Obfsproxy uses modules called pluggable transports to obfuscate underlying traffic. Different transports may or may not use encryption and have different implementation and choices over encryption schemes. +Obfsproxy опционально использоется так, чтобы VPN-трафик не распознавался как VPN-трафик для кого-либо, кто осуществляет мониторинг сети. Obfsproxy использует модули, называемые встраиваемыми транспортами, чтобы скрыть основной трафик. Различные транспорты могут использовать или не использовать шифрование и иметь различные реализации и выбор схем шифрования. -We have chosen the Scramblesuit pluggable transport that uses Uniform Diffie-Hellman for the initial handshake and AES-CTR 256 for application data. +Мы выбрали подключаемый транспорт Scramblesuit, который использует унифицированный Диффи-Хеллмана для начального рукопожатия и AES-CTR 256 для данных приложения. -h2. Encrypted Email - OpenPGP +h2. Зашифрованная электронная почта - OpenPGP -The user's autogenerated key pair uses 4096 bit RSA for the master signing key. +Автоматически генерируемая пара ключей пользователя использует 4096-битный RSA для главного подписывающего ключа. -Bitmask will refuse to encrypt to a recipient's public key if the length is 1024 or less. +Bitmask откажется шифровать открытым ключом получателя, если его длина составляет 1024 бита или менее. -All keys are stored in Soledad. +Все ключи хранятся в Soledad. -Bitmask does not yet support ECC keys. +Bitmask пока не поддерживает ECC ключи. -Bitmask uses GnuPG. The python library we use is [[Isis's fork of python-gnupg => https://github.com/isislovecruft/python-gnupg]]. +Bitmask использует GnuPG. Библиотекой python, которую мы используем, является [[форк Айсис python-gnupg => https://github.com/isislovecruft/python-gnupg]]. -h2. Secure Updates - TUF +h2. Безопасные обновления - TUF -The secure updates are done using [[TUF => http://theupdateframework.com/]], they use OpenSSL 4096 RSA keys with pyCrypto. There is three keys involved in the update process (root, targets and timestamp). +Безопасные обновления осуществляется с помощью [[TUF => http://theupdateframework.com/]], они используют 4096-битные RSA-ключи OpenSSL с pyCrypto. Существует три ключа, участвующие в процессе обновления (корневой, целевой и временной метки). -* The root key is used to certify the rest of the keys that lives in an offline storage and only gets used once per year to update the cerification or in case of rotation of another other key. -* The targets key is used to sign all the updates. This key is in the hands of the release manager and used on every release. -* The timestamp key is used to sing a timestamp file every day, this file is used by the client to prevent an adversary from replaying an out-of-date updates. This key lives online in the platform servers. +* Корневой ключ используется для подтверждения остальных ключей, которые живут в автономном хранилище и используются только один раз в год, чтобы обновить сертификацию или в случае ротации другого ключа. +* Целевой ключ используется для подписи всех обновлений. Этот ключ находится в руках менеджера версий и используются для каждой версии приложения. +* Ключ временной метки используется для подписи временной метки файла каждый день, этот файл используется клиентом, чтобы предотвратить противника от воспроизведения устаревших обновлений. Этот ключ живет онлайн на серверах платформы. -h2. Other +h2. Разное h3. OpenSSH -By default, all servers use RSA key host keys instead of ECDSA. If a host has a ECDSA key, the platform will prompt the sysadmin to switch to RSA. In the future, when Curve255219 is better supported, the platform will encourage switching to 25519. +По умолчанию, все серверы используют RSA-ключи хостов вместо ECDSA. Если у хоста ECDSA-ключ, платформа предложит системному администратору перейти на RSA. В будущем, когда Curve255219 будет лучше поддерживаться, платформа будем поощрять переход на 25519. h3. DNSSec -To be written +Будет написано. h3. StartTLS + DANE -To be written +Будет написано.
\ No newline at end of file diff --git a/pages/features/email/ru.text b/pages/features/email/ru.text index b2785de..82d262c 100644 --- a/pages/features/email/ru.text +++ b/pages/features/email/ru.text @@ -1,116 +1,116 @@ @title = "Подробности электронной почты Bitmask" @nav_title = "Электронная почта" -h2. How to use it +h2. Как этим пользоваться -# Download and install the Bitmask application. -# Run the Bitmask application to log in or sign up with the service provider. -# Configure the user's mail client to connect to the local IMAP and SMTP services provided by the Bitmask application. In case of the Thunderbird email client, this configuration is semi-automatic. +# Скачайте и установите приложение Bitmask. +# Запустите приложение Bitmask, чтобы авторизоваться или зарегистрироваться на сервис-провайдере. +# Настройте почтовый клиент пользователя для соединения с локальными сервисами IMAP и SMTP, предоставленными приложением Bitmask. В случае работы с почтовым клиентом Thunderbird, эта конфигурация будет полуавтоматической. -The Bitmask application acts as a local "proxy" between the service provider and the mail client. It handles all the encryption and data synchronization. +Приложение Bitmask выступает в качестве локального "прокси" между сервис-провайдером и почтовым клиентом. Оно обрабатывает все шифрование и синхронизацию данных. -h2. Benefits of Bitmask Email +h2. Преимущества электронной почты Bitmask -Email features include: +Возможности электронной почты включают: -* Bitmask encrypted email is easy to use while still being backward compatible with the existing protocols for secure email (currently OpenPGP, with additional support for S/MIME coming in the future). -* Unless already encrypted, all incoming email is automatically encrypted to the recipient on the server before being stored, so only you can read it (including meta-data). The server is able to read unencrypted incoming email for a brief moment, but no email is ever stored in a manner that the provider can read it. -* Whenever possible, outgoing email is automatically encrypted so that only the recipients can read it (if a valid public keys can be discovered for the recipients). This encryption takes place on the user's device. -* Public keys are [[automatically discovered and validated => https://leap.se/nicknym]], allowing you to have confidence your communication is confidential and with the correct person (without the headache of typical key signing). -* The user does not need to worry about key management. Their keys are always kept up-to-date on every device. -* The user is able to use any email client of their choice (e.g. Thunderbird, Apple Mail, Outlook). -* When disconnected from the internet, the user can still interact with a local copy of all their mail. When the internet connect is available again, all their changes will get synchronized with the server storage and to their other devices. +* Зашифрованная почта Bitmask проста в использовании и в то же время обратно совместима с существующими протоколами для безопасной электронной почты (в настоящее время это OpenPGP, с дополнительной поддержкой для S/MIME в будущем). +* Все входящие сообщения, даже если они еще не зашифрованы, автоматически шифруются получателю на сервере перед сохранением, так что только вы можете прочитать их (в том числе мета-данные). Сервер может прочитать незашифрованную входящую почту на мгновение, но никакая почта не хранится когда-либо таким образом, что провайдер может прочесть ее. +* Всякий раз, когда это возможно, исходящая почта автоматически шифруется таким образом, что только получатели могут ее прочесть (если действующие открытые ключи могут быть обнаружены для получателей). Это шифрование происходит на устройстве пользователя. +* Открытые ключи [[автоматически обнаруживаются и подтверждаются => https://leap.se/nicknym]], позволяя вам быть уверенными, что ваша коммуникация является конфиденциальной и с соответствующим человеком (без головной боли типичной подписи ключей) +* Пользователю не нужно беспокоиться об управлении ключами. Их ключи постоянно актуальны на каждом устройстве. +* Пользователь может использовать любой почтовый клиент по своему усмотрению (напр., Thunderbird, Apple Mail, Outlook). +* После отключения от интернета пользователь может по-прежнему взаимодействовать с локальной копией всей своей почты. Когда интернет-соединение снова будет доступно, все изменения синхронизируются с сервером хранения и другими устройствами пользователя. -General security features of the Bitmask application include: +Общие характеристики безопасности приложения Bitmask включают: -* All stored data is encrypted, including local data and cloud backups. This encryption always [[takes place on the user's device => https://leap.se/soledad]], so the service provider cannot read your stored data. -* Although you specify a username and password to login, your [[password is never communicated to the provider => https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol ]]. -* If you download the Bitmask application from https://dl.bitmask.net, your service provider cannot add a backdoor to compromise your security. -* The Bitmask application is always kept up to date with the latest security patches (coming soon). +* Все данные хранятся в зашифрованном виде, в том числе локальные данные и облачные резервные копии. Шифрование всегда [[происходит на устройстве пользователя => https://leap.se/soledad]], поэтому сервис-провайдер не может читать ваши сохраненные данные. +* Несмотря на то, что вы указываете имя пользователя и пароль для авторизации, [[пароль никогда не передается провайдеру => https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol]]. +* Если вы скачиваете приложение Bitmask с https://dl.bitmask.net, ваш сервис-провайдер не может добавить бэкдор, чтобы скомпрометировать вашу безопасность. +* Приложение Bitmask всегда находится в актуальном состоянии относительно последних патчей безопасности (будет в ближайшее время). -h2. How it works +h2. Как это работает -NOTE: technical jargon ahead. +ПРИМЕЧАНИЕ: впереди технический жаргон. -h3. Receiving mail +h3. Получение почты -*Message reception and storage* +*Получение и хранение сообщения* -# An incoming email is received by the provider's MX (mail exchange) server. -# The MX server re-encrypts the incoming email using the public key of the recipient user. This happens even if the email is already encrypted so that the metadata is not stored in a way that anyone but the recipient may access it. -# The user logs in to their Bitmask client: -## The client unlocks the locally encrypted storage database. -## The client asks the server if there is any new data and begins a synchronization process. -# The client downloads the new incoming message. -# The message is decrypted using the user's private key, and then stored in the locally encrypted storage database. -# The local storage database is synchronized with the provider's cloud storage service. To be stored on the server, a unique key generate for each document in the local storage database before it is sent to the server (see [[Soledad => https://leap.se/en/soledad]] for more details). -# If the user has the Bitmask client running on other devices, then these clients will notice the change to the storage database and re-synchronize. +# Входящая почта получается MX-сервером (mail exchange - обмен почтой) провайдера. +# MX-сервер повторно шифрует входящую почту с помощью открытого ключа получателя. Это происходит, даже если почта уже зашифрована, так что метаданные не хранятся таким образом, что любой кроме получателя может получить к ним доступ. +# Пользователь авторизируется в своем клиенте Bitmask: +## Клиент разблокирует базу данных, зашифрованную локально. +## Клиент спрашивает у сервера, есть ли какие-либо новые данные, и начинает процесс синхронизации. +# Клиент загружает новое входящее сообщение. +# Сообщение расшифровывается с помощью закрытого ключа пользователя, а затем сохраняется в базе данных, зашифрованной локально. +# Локальная база данных синхронизируется с облачной службой хранения провайдера. Для хранения на сервере генерируется уникальный ключ для каждого документа в локальной базе данных перед отправкой на сервер (смотрите [[Soledad => https://leap.se/en/soledad]] для более подробной информации). +# Если у пользователя есть клиент Bitmask, работающий на других устройствах, то эти клиенты заметят изменения в базе данных и выполнят повторную синхронизацию. -*Message validation* +*Проверка сообщения* -# If the received message was signed, the client will attempt to validate the signature. -# If the sender's public key is not already known to the client's key manager, the client will attempt to acquire it: -## If the email was sent from a LEAP-powered provider, the key will be anonymously requested from the sender's provider. -## If the public key is attached to the email, it will be imported. -## If the email contains an OpenPGP header, the client will download the public key from the specified source. -## If all else fails, the client will search OpenPGP keyservers for a key that matches the fingerprint on the signature. -# Once acquire, the sender's public key is stored in the locally encrypted and synchronized storage database. -# Public keys are updated using the rules for [[transitional key validation => https://leap.se/en/transitional-key-validation]]. +# Если полученное сообщение было подписано, клиент попытается проверять подпись. +# Если открытый ключ отправителя еще неизвестен менеджеру ключей клиента, клиент попытается его приобрести: +## Если сообщение было отправлено с LEAP-совместимого провайдера, ключ будет анонимно запрошен с провайдера отправителя. +## Если открытый ключ прикреплен к сообщению, он будет импортирован. +## Если сообщение содержит заголовок OpenPGP, клиент загрузит открытый ключ из указанного источника. +## Если все остальное не удается, клиент будет искать OpenPGP серверы ключей для ключа, который соответствует отпечатку на подписи. +# После приобретения открытый ключ отправителя хранится в зашифрованной локально и синхронизированной базе данных. +# Открытые ключи обновляются с помощью правил для [[переходной проверки ключей => https://leap.se/en/transitional-key-validation]]. -*Reading the message* +*Чтение сообщения* -The user can read the email in one of two ways: +Пользователь может читать электронную почту двумя способами: -# By connecting a mail user agent, such as Thunderbird, to the local IMAP server created by Bitmask. -# By launching the built-in mail app (in progress, not part of current stable releases). +# Подключив почтовый агент, такой как Thunderbird, к локальному IMAP-серверу, созданному Bitmask. +# Запустив встроенное почтовое приложение (в процессе, пока не входит в текущие стабильные версии). -h3. Sending mail +h3. Отправка почты -*Composing the message* +*Составление сообщения* -The user can compose an email in one of two ways: +Пользователь может написать сообщение двумя способами: -# By connecting a mail user agent, such as Thunderbird, to the local SMTP server created by Bitmask. -# By launching the built-in mail app (in progress, not part of current stable releases). +# Одключив почтовый агент, такой как Thunderbird, к локальному SMTP-серверу, созданному Bitmask. +# Запустив встроенное почтовое приложение (в процессе, пока не входит в текущие стабильные версии). -*Encrypting the message* +*Шифрование сообщения* -# The client's key manager acquires the public key for each recipient, if not already stored. -## The key manager tries whatever means it can. Currently, this includes anonymously contacting the recipient's provider and searching OpenPGP keyservers, and will include DANE/DNSSec and CONIKS in the future. -## Discovered keys are stored in the locally encrypted storage database, and synchronized among the user's devices. -# The message is duplicated into separate copies, once for each recipient, and each copy is encrypted for one recipient and relayed for delivery. +# Менеджер ключей клиента приобретает открытый ключ для каждого получателя, если он еще не сохранен. +## Менеджер ключей пытается любыми способами, какими только он может. В настоящее время это включает анонимное контактирование с провайдером получателя и поиск OpenPGP серверов ключей, и будет включать DANE/DNSSec и CONIKS в будущем. +## Обнаруженные ключи сохраняются в локально зашифрованной базе данных и синхронизированы между устройствами пользователя. +# Сообщение дублируется в отдельные копии, по одному для каждого получателя, и каждая копия шифруется для одного получателя и передается для доставки. -*Relaying the message* +*Передача сообщения* -Currently: +В настоящее время: -# The Bitmask client connects to MX server of the sender's provider. This connection is authenticated using a X.509 client certificate stored by the client, a separate one for each sender email address. -# If the client certificate matches the "From" field of the email, then the email is DKIM signed and relayed to the destination MX server. +# Клиент Bitmask подключается к MX-серверу провайдера отправителя. Это соединение проходит проверку подлинности с использованием сертификата клиента X.509, сохраненного клиентом, отдельно для каждого адреса электронной почты отправителя. +# Если сертификат клиента соответствует полю "От" в сообщении, то электронная почта подписывается DKIM и передается на конечный MX-сервер. -In the future (currently being developed): +В будущей (разрабатывается в настоящее время): -# The Bitmask client checks to see if the recipient supports delivery via Panoramix (anonymous mix network). -** If supported, the client checks to see if the sender has permission to deliver anonymously to the recipient (via special delivery keys). -** If delivery permission is granted, the email message will be directly delivered to the recipient's provider using Panoramix. In this case, the sender's provider will never see the email. -# If Panoramix is not available, the Bitmask client connects to MX server of the sender's provider. This connection is authenticated using a X.509 client certificate stored by the client, a separate one for each sender email address. -# If the client certificate matches the "From" field of the email, then the email is DKIM signed and relayed to the destination MX server. +# Клиент Bitmask проверяет, поддерживает ли получатель доставку через Panoramix (анонимную смешанную сеть). +** Если поддерживает, клиент проверяет, есть ли у отправителя разрешение на анонимную доставку получателю (с помощью специальных ключей доставки). +** Если разрешение на доставку предоставлено, сообщение будет доставлено непосредственно провайдеру получателя с помощью Panoramix. В этом случае провайдер отправителя никогда не будет видеть электронную почту. +# Если Panoramix не доступен, клиент Bitmask подключается к MX-серверу провайдера отправителя. Это соединение проходит проверку подлинности с использованием сертификата клиента X.509, сохраненного клиентом, отдельно для каждого адреса электронной почты отправителя. +# Если сертификат клиента соответствует полю "От" в сообщении, то электронная почта подписывается DKIM и передается на конечный MX-сервер. -h2. Limitations +h2. Ограничения -* Missing features: the initial release will not support email aliases, email forwarding, or multiple accounts simultaneously. -* You cannot use Bitmask email from a web browser. It requires the Bitmask application to run. -* The Bitmask application currently requires a compatible provider. We have plans in the future to semi-support commercial providers like gmail. This would provide the user with much less protection than when they use a Bitmask provider, but will still greatly enhance their email security. -* Because all data is synced, if a user has one of their devices compromised, then the attacker has access to all their data. This is obvious, but worth mentioning. -* The user must keep a complete copy of their entire email storage on every device they use. In the future, we plan to support partial syncing for mobile devices. -* We do not plan to support key revocation. Instead, we plan to migrate to shorter and shorter lived keys, as practical. -* With the current implementation, a compromised or nefarious service provider can still gather incoming messages that are not encrypted and meta-data routing information. For the future, we are working on a project called Panoramix that will allow for message routing that is anonymous and exposes zero meta-data information to the service provider (so long as both sender and recipient support Panoramix). -* OpenPGP and S/MIME message encryption has no forward secrecy, although we do use PFS ciphers for StartTLS relay. In the future, we hope to add additional forms of message encryption, such as Axolotl. -* With our current scheme of automatic key validation, there is a chance that a provider could endorse a bogus public key for a short period of time such that the holder of the correct key does not notice the subterfuge. In the future, we hope to add compatibility with CONIKS, which supports an cryptographic append-only log of all key endorsements and allows for strong auditing of these past endorsements. +* Отсутствующие возможности: первая версия не будет поддерживать псевдонимы электронной почты, пересылку электронной почты или несколько учетных записей одновременно. +* Вы не можете использовать электронную почту Bitmask из веб-браузера. Нужно, чтобы приложение Bitmask было запущено. +* Приложению Bitmask в настоящее время требуется совместимый провайдер. У нас есть планы в будущем полуподдерживать коммерческих провайдеров, таких как Gmail. Это обеспечило бы пользователю гораздо меньшую защиту, чем в случае использования провайдера Bitmask, но по-прежнему в значительной степени повысило бы безопасность электронной почты. +* Поскольку все данные синхронизируются, если у пользователя одно из его устройств скомпрометировано, то злоумышленник будет иметь доступ ко всем его данным. Это очевидно, но стоит упомянуть. +* Пользователь должен держать полную копию всей электронной переписки на каждом устройстве, которое он использует. В будущем мы планируем поддерживать частичную синхронизацию для мобильных устройств. +* Мы не планируем поддерживать отзыв ключа. Вместо этого мы планируем переходить на все менее и менее живущие ключи, насколько это практически возможно. +* В текущей реализации скомпрометированный или бесчестный сервис-провайдер все еще может собирать входящие сообщения, которые не зашифрованы, и мета-данные информации о маршрутизации. В перспективе, мы работаем над проектом под названием Panoramix, который позволит маршрутизацию сообщений, которая будет анонимной и не будет раскрывать никакую информацию о мета-данных сервис-провайдеру (до тех пор пока отправитель и получатель поддерживают Panoramix). +* OpenPGP и S/MIME-шифрование сообщений не имеет прямой секретности, хотя мы используем PFS шифры для StartTLS передачи. В будущем мы надеемся добавить дополнительные формы шифрования сообщений, такие как Axolotl. +* С нашей нынешней схемой автоматической проверки ключей, есть шанс, что провайдер может одобрить поддельный открытый ключ в течение короткого промежутка времени так, что владелец правильного ключа не заметит уловки. В будущем мы надеемся добавить совместимость с CONIKS, который поддерживает криптографический журнал только на добавление всех согласований ключей и дает возможность сильного аудита этих прошедших согласований. -For more details, please see [[known limitations => https://leap.se/en/limitations]]. +Для более подробной информации смотрите [[известные ограничения => https://leap.se/en/limitations]]. -h2. Related projects +h2. Похожие проекты -There are numerous other projects working on the next generation of secure email. In our view, it is not possible to do secure email alone, it requires new protocols for handing key validation, secure transport, and meta-data protection. We will continue our efforts to reach out to these groups to explore areas of cooperation. +Существуют множество других проектов, работающих над следующим поколением безопасной электронной почты. На наш взгляд, невозможно сделать безопасной электронную почту в одиночку, необходимы новые протоколы для передачи проверки ключей, безопасной транспортировки и защиты мета-данных. Мы продолжим наши усилия для достижения этих групп для того, чтобы исследовать направления сотрудничества. -For a detailed report on all the related projects, see https://leap.se/secure-email +Для подробного отчета о всех связанных проектах, смортите https://leap.se/secure-email.
\ No newline at end of file |