diff options
Diffstat (limited to 'pages/features')
| -rw-r--r-- | pages/features/cryptography/en.text | 66 | ||||
| -rw-r--r-- | pages/features/cryptography/pt.text | 53 | ||||
| -rw-r--r-- | pages/features/cryptography/ru.text | 54 | ||||
| -rw-r--r-- | pages/features/email/en.text | 116 | ||||
| -rw-r--r-- | pages/features/email/future notes | 16 | ||||
| -rw-r--r-- | pages/features/email/pt.text | 116 | ||||
| -rw-r--r-- | pages/features/email/ru.text | 116 | ||||
| -rw-r--r-- | pages/features/en.haml | 38 | ||||
| -rw-r--r-- | pages/features/es.haml | 28 | ||||
| -rw-r--r-- | pages/features/pt.haml | 29 | ||||
| -rw-r--r-- | pages/features/ru.haml | 10 | ||||
| -rw-r--r-- | pages/features/vpn/ru.text | 2 |
12 files changed, 17 insertions, 627 deletions
diff --git a/pages/features/cryptography/en.text b/pages/features/cryptography/en.text index 7cc32f4..c1c89f5 100644 --- a/pages/features/cryptography/en.text +++ b/pages/features/cryptography/en.text @@ -41,44 +41,6 @@ The provider-specific CA certificates use 4096 bit RSA with SHA256 digest, by de All TLS connections use PFS ciphers. -h2. Storage - 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. - -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). - -Currently, our scrypt parameters are: - -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 - -We are considering using a larger 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. - -*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: - -<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 -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((. 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. - -*Transport* - -p((. TLS, as above. Soon to be CurveZMQ. - h2. Encrypted Tunnel - 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. @@ -116,36 +78,8 @@ Obfsproxy is optionally used to make VPN traffic not appear as VPN traffic to so We have chosen the Scramblesuit pluggable transport that uses Uniform Diffie-Hellman for the initial handshake and AES-CTR 256 for application data. -h2. Encrypted Email - OpenPGP - -The user's autogenerated key pair uses 4096 bit RSA for the master signing key. - -Bitmask will refuse to encrypt to a recipient's public key if the length is 1024 or less. - -All keys are stored in Soledad. - -Bitmask does not yet support ECC keys. - -Bitmask uses GnuPG. The python library we use is [[Isis's fork of python-gnupg => https://github.com/isislovecruft/python-gnupg]]. - -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 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. - h2. Other 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. - -h3. DNSSec - -To be written - -h3. StartTLS + DANE - -To be written diff --git a/pages/features/cryptography/pt.text b/pages/features/cryptography/pt.text index f532879..b49dfc8 100644 --- a/pages/features/cryptography/pt.text +++ b/pages/features/cryptography/pt.text @@ -41,44 +41,6 @@ Os certificados CA específicos de provedores usam RSA de 4096 bit com digest de Todas as conexões TLS usan cifras PFS. -h2. Armazenamento - Soledad - -A aplicação Bitmask armazena seus próprios dados na [[Soledad => https://leap.se/soledad]], que lida com a encriptação desses dados, fazendo backups seguros, e sincroniza-os entre os dispositivos do usuário. Na Soledad, o armazenamento local utiliza bloco simétrico de encriptação de toda a base de dados usando uma única chave. Para os dados armazenados remotamente, cada documento é encriptado separadamente usando uma chave única para cada um deles. - -Tanto as chaves do armazenamento local quanto as do remoto derivam de um "segredo de armazenamento" mestre. Este segredo longo e aleatório é armazenado localmente no disco, protegido por encriptação simétrica usando uma chave derivada da senha de usuário (scrypt é usado como função de derivação da chave). - -Atualmente, nossos parâmetros para o scrypt são: - -bc. N (CPU/parâmetro de custo de memória) = 2^14 = 16384 -p (parâmetro de paralelização) = 1 -r (tamanho do bloco misturado pelo SMix()) = 8 -dkLen (tamanho da chave derivada) = 32 bytes = 256 bits - -Estamos vendo de usar um N maior. - -*Armazenamento local* - -p((. A base de dados SQLite local encriptada em bloco usa @AES-256-CBC@ usando os primeiros 256 bits do [@segredo de armazenamento@]. Ver https://github.com/kalikaneko/python-u1dbcipher and http://sqlcipher.net. - -*Armazenamento remoto* - -p((. A encriptação de cada documento no armazenamento remoto usa encriptação simétrica com AES-256-CTR ou cifra XSalsa20 usando chaves de 256 bit. Usamos a biblioteca pycryptopp para isso. A chave e o MAC usados para encriptar cada documento individualmente são derivados da seguinte forma: - -<pre style="margin-left: 2em"> -storage_secret_a = primeiros 256 bits do segredo de armazenamento -storage_secret_b = tudo que venha depois dos primeiros 256 bits do segredo de armazenamento -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((. Cada documento possui sua própria chave. A [@revisão do documento@] no MAC do documento previne a sobreposição de uma antiga versão sobre uma nova. HMAC usa SHA256. - -p((. Alguns documentos nos dados remotos de usuário são adicionados pelo provedor, tais como no caso de novos emails. Estes documentos usam encriptação assimétrica, sendo cada documento encriptado usando a chave pública OpenPGP do usuário. Usamos a biblioteca derivada do python-gnupg [[Isis => https://github.com/isislovecruft/python-gnupg]] para isso. Esses documentos são armazenados apenas temporariamente dessa forma: assim que o cliente os tiver visto, eles são desencriptados e re-encriptados usando os outros métodos. - -*Transporte* - -p((. TLS, como acima. Em breve será com CurveZMQ. - h2. Tunel Encriptado - OpenVPN OpenVPN possui três configurações que controlam quais cifras são usadas (existe uma quarta, @--tls-auth@, mas ainda não podemos usá-la num ambiente público de múltiplos usuários). Cada provedor pode facilmente escolher a opção que quiser. Abaixo estão os padrões atuais que vêm com a plataforma LEAP. @@ -128,24 +90,9 @@ O Bitmask ainda não suporta chaves ECC. O Bitmask usa GnuPG. A biblioteca em python que usamos é a [[ramificação Isis do python-gnupg => https://github.com/isislovecruft/python-gnupg]]. -h2. Atualizações de Segurança - TUF - -As atualizações de segurança são feitas usando o [[TUF => http://theupdateframework.com/]], que usa chaves RSA OpenSSL 4096 com pyCrypto. Existe três chaves envolvidas no processo de atualização (root, targets e timestamp). - -* A chave 'root' é usada para certificar o resto das chaves que estão armazenadas offline e é usada somente uma vez por ano para atualizar a certificação ou no caso de mudança de alguma outra chave [key rotation]. -* A chave 'targets' é usada para assinar todas as atualizações. Esta chave está nas mãos do gerenciador de lançamentos [release] e é usada a cada nova versão. -* A chave 'timestamp' é usada para assinar um arquivo com data e hora a cada dia. Este arquivo é usada pelo cliente para prevenir que um adversário imponha uma atualização antiga. Esta chave está online nos servidores da plataforma. - h2. Outros h3. OpenSSH Por padrão, todos os servidores usam chave RSA para guardar as chaves ao invés de ECDSA. Se um 'host' possui uma chave ECDSA, a plataforma irá sugerir ao 'sysadmin' que mude para RSA. No futuro, quando o Curve255219 for bem suportado, a plataforma instigará a mudar para 25519. -h3. DNSSec - -Ainda será escrito. - -h3. StartTLS + DANE - -Ainda será escrito. diff --git a/pages/features/cryptography/ru.text b/pages/features/cryptography/ru.text index 3c4b419..a96a9ef 100644 --- a/pages/features/cryptography/ru.text +++ b/pages/features/cryptography/ru.text @@ -41,44 +41,6 @@ h2. Транспорт - TLS Все TLS-соединения используют шифры PFS. -h2. Хранение - Soledad - -Приложение Bitmask хранит свои данные в [[Soledad => https://leap.se/soledad]], который занимается шифрованием этих данных, надежно делает их резервные копии и синхронизирует их между устройствами пользователя. В Soledad локальное хранилище использует симметричное блочное шифрование всей базы данных с использованием единственного ключа. Для данных, хранящихся удаленно, каждый отдельный документ отдельно шифруется с использованием ключа, уникального для этого документа. - -Оба ключа для локального и удаленного хранилищ получаются из главного "секретного значения хранилища". Это длинное случайное секретное значение хранилища хранится на диске локально, защищенное симметричным шифрованием с помощью ключа, полученного из пароля пользователя (scrypt используется в качестве функции формирования ключа). - -На данный момент параметры scrypt такие: - -bc. N (параметр стоимости соотношения время/память) = 2^14 = 16384 -p (степень параллельности) = 1 -r (длина блока, перемешиваемого SMix()) = 8 -dkLen (длина выходного ключа) = 32 байта = 256 бит - -Мы рассматриваем использование большего значения для N. - -*Локальное хранение* - -p((. Локальная база данных SQLite с блочным шифрованием использует @AES-256-CBC@, используя первые 256 бит [@storage_secret@]. Смотрите https://github.com/kalikaneko/python-u1dbcipher и http://sqlcipher.net. - -*Удаленное хранение* - -p((. Подокументное шифрование документов, хранящихся удаленно, использует симметричное шифрование с AES-256-CTR или шифр XSalsa20, использующий 256-битные ключи. Для этого используется библиотека pycryptopp. Ключ и MAC, используемые для шифрования каждого отдельного документа, получаются следующим образом: - -<pre style="margin-left: 2em"> -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((. Каждый документ имеет свой собственный ключ. [@document_revision@] в MAC документа предотвращает откат к старой версии документа. HMAC использует SHA256. - -p((. Некоторые документы в удаленном хранилище данных пользователя добавляются провайдером, например, в случае нового входящего сообщения электронной почты. Эти документы используют асимметричное шифрование, с каждым документом, зашифрованным с использованием пользовательского открытого OpenPGP-ключа. Библиотекой, которую мы используем для этого, является [[форк Айсис python-gnupg => https://github.com/isislovecruft/python-gnupg]]. Эти документы лишь временно хранятся пободным образом: как только клиент увидит их, они остаются в незашифрованном виде и повторно шифруются с использованием других методов. - -*Транспорт* - -p((. TLS, как описано выше. Скоро будет CurveZMQ. - h2. Зашифрованный туннель - OpenVPN OpenVPN имеет три параметра, которые управляют тем, какие шифры он использует (есть и четвертый, @--tls-auth@, но мы не можем его использовать в публичном многопользовательском окружении). Каждый провайдер может легко выбрать любые опции по своему желанию. Ниже приведены текущие значения по умолчанию, которые идут с leap_platform. @@ -127,24 +89,8 @@ Bitmask пока не поддерживает ECC ключи. Bitmask использует GnuPG. Библиотекой python, которую мы используем, является [[форк Айсис python-gnupg => https://github.com/isislovecruft/python-gnupg]]. -h2. Безопасные обновления - TUF - -Безопасные обновления осуществляется с помощью [[TUF => http://theupdateframework.com/]], они используют 4096-битные RSA-ключи OpenSSL с pyCrypto. Существует три ключа, участвующие в процессе обновления (корневой, целевой и временной метки). - -* Корневой ключ используется для подтверждения остальных ключей, которые живут в автономном хранилище и используются только один раз в год, чтобы обновить сертификацию или в случае ротации другого ключа. -* Целевой ключ используется для подписи всех обновлений. Этот ключ находится в руках менеджера версий и используются для каждой версии приложения. -* Ключ временной метки используется для подписи временной метки файла каждый день, этот файл используется клиентом, чтобы предотвратить противника от воспроизведения устаревших обновлений. Этот ключ живет онлайн на серверах платформы. - h2. Разное h3. OpenSSH По умолчанию, все серверы используют RSA-ключи хостов вместо ECDSA. Если у хоста ECDSA-ключ, платформа предложит системному администратору перейти на RSA. В будущем, когда Curve255219 будет лучше поддерживаться, платформа будем поощрять переход на 25519. - -h3. DNSSec - -Будет написано. - -h3. StartTLS + DANE - -Будет написано.
\ No newline at end of file diff --git a/pages/features/email/en.text b/pages/features/email/en.text deleted file mode 100644 index fe00a40..0000000 --- a/pages/features/email/en.text +++ /dev/null @@ -1,116 +0,0 @@ -@title = "Bitmask Email Details" -@nav_title = "Email" - -h2. How to use it - -# 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. - -The Bitmask application acts as a local "proxy" between the service provider and the mail client. It handles all the encryption and data synchronization. - -h2. Benefits of Bitmask Email - -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. - -General security features of the Bitmask application include: - -* 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). - -h2. How it works - -NOTE: technical jargon ahead. - -h3. Receiving mail - -*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. - -*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]]. - -*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). - -h3. Sending mail - -*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). - -*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. - -*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. - -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. - -h2. Limitations - -* 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. - -For more details, please see [[known limitations => https://leap.se/en/limitations]]. - -h2. Related projects - -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 diff --git a/pages/features/email/future notes b/pages/features/email/future notes deleted file mode 100644 index 367ef5b..0000000 --- a/pages/features/email/future notes +++ /dev/null @@ -1,16 +0,0 @@ - -h2. Long term benefits when two Bitmask compatible providers talk to one another - -One of the fundamental problems with email is that the meta-data routing information is exposed as cleartext. Encrypting a message with OpenPGP or S/MIME does nothing to help with this. - -The email protocol does support an optional method of securely relaying messages using TLS to encrypt the connection. This method, called StartTLS, is easily undermined by attackers and there is no good way for email providers to validate the authenticity of other servers (without relying on the problematic CA certificate authority system). - -For now, Bitmask addresses these problems with two enhancements when two compatible providers are talking to one another: - -* When relaying email, server keys are discovered and validated using DNSSEC/DANE. -* For these providers, TLS with validated keys becomes required for all communication. - -This approach is effective against external network observers, but does not protect the meta-data from the service providers themselves. Also, it does not, by itself, protect against more advanced attacks involving timing and traffic analysis. - -In the long term, we plan to adopt one of several different schemes for [[securely routing meta-data => https://leap.se/routing]]. - diff --git a/pages/features/email/pt.text b/pages/features/email/pt.text deleted file mode 100644 index afc344b..0000000 --- a/pages/features/email/pt.text +++ /dev/null @@ -1,116 +0,0 @@ -@title = "Detalhes sobre o Email Bitmask" -@nav_title = "Email" - -h2. Como usar - -# Baixe e instale o Bitmask. -# Rode o Bitmask para logar ou criar uma conta num provedor de serviços. -# Configure o cliente de email de usuário para se conectar aos serviços de IMAP local e SMTP fornecido pelo Bitmask. No caso do cliente de email Thunderbird, esta configuração é semiautomática. - -O Bitmask age como um "proxy" local entre o provedor de serviço e o cliente de email. Ele lida com toda a parte de encriptação e sincronização de dados. - -h2. Benefícios do Email Bitmask - -Como funcionalidades do email temos: - -* O email encriptado Bitmask é fácil de usar ao mesmo tempo que continua compatível com os protocolos existente para email seguros (atualmente OpenPGP, e em breve com suporte adicional para S/MIME). -* Ao menos que já estejam encriptados, todos os emails novos são automaticamente encriptados para o destinatário no servidor antes de ser armazenado, para que só você consiga lê-los (inclusive metadados). O servidor é capaz de ler emails não encriptados por um breve momento, mas jamais um email é armazenado de forma que o servidor possa lê-lo. -* Sempre que possível, emails enviados são automaticamente encriptados de forma que apenas o destinatário possa lê-los (se uma chave pública for encontrada para esse destinatário). Esta encriptação acontece no aparelho do usuário. -* As chaves públicas são [[automaticamente encontradas e validadas => https://leap.se/nicknym]], dando-lhe a confiança de que suas comunicações são confidenciais e enviadas para a pessoa certa (sem a dor de cabeça de fazer a assinatura com chave). -* O usuário não precisa se preocupar com o gerenciamento de chaves. Suas chaves sempre estão atualizadas em cada aparelho. -* O usuário pode usar qualquer cliente de email (e.g. Thunderbird, Apple Mail, Outlook). -* Quando desconectar da internet, o usuário ainda consegue interagir com sua cópia local de todos os seus emails. Quando uma conexão estiver disponível novamente, todas as mudanças são sincronizadas com o que foi armazenado no servidor e nos seus outros aparelhos. - -Características gerais de segurança do Bitmask: - -* Todos os dados armazenados são encriptados, incluindo dados locais e backups na nuvem. Esta encriptação sempre [[acontece no aparelho do usuário => https://leap.se/soledad]], para que o provedor de serviço não consiga ler seus dados armazenados. -* Embora você especifique um nome de usuário e uma senha para logar, sua [[senha nunca vai para o provedor => https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol ]]. -* Se você baixar o Bitmask de https://dl.bitmask.net, seu provedor de serviço não poderá colocar uma backdoor que comprometa sua segurança. -* O Bitmask está sempre atualizado com os últimos correções (patches) de segurança (em breve). - -h2. Como funciona - -NOTE: jargões técnicos à frente. - -h3. Recebendo emails - -*Recebimento e armazenamento de mensagens* - -# O servidos MX (mail exchange) do provedor recebe um email. -# O servidor MX re-encripta o email recebido usando a chave pública do destinatário. Isso acontece mesmo que o email já esteja encriptado para que o metadado não seja guardado visível para ninguém além do destinatário. -# O usuário loga no seu cliente Bitmask: -## O cliente desbloqueia a base de dados armazenada encriptada localmente. -## O cliente pergunta ao servidor se há algum dado novo e começa o processo de sincronização. -# O cliente baixa as novas mensagens. -# A mensagem é desencriptada usando a chave privada do usuário e, em seguida, é armazenada na base da dados encriptada localmente. -# A base de dados local é sincronizada com o serviço de armazenamento na nuvem do provedor. Para ser armazenada no servidor, uma chave única é gerada para cada documento na base de dados local antes que seja enviada para o servidor (veja [[Soledad => https://leap.se/en/soledad]] para mais detalhes). -# Se o usuário está com o cliente Bitmask rodando em outros aparelhos, então estes clientes serão notificados que houve uma mudança na base de dados e re-sincronizados. - -*Validação da mensagem* - -# Se a mensagem recebida foi assinada, o cliente tentará validar a assinatura. -# Se a chave pública do remetente ainda não é conhecida pelo gerenciador de chaves do cliente, o cliente tentará adquiri-la: -## Se o email foi enviado por um provedor alimentado pelo LEAP, a chave será requisitada anonimamente ao provedor do remetente. -## Se a chave pública veio anexada ao email, ela será importada. -## Se o email contém um cabeçalho OpenPGP, o cliente baixará a chave pública da fonte especificada no cabeçalho. -## Se tudo isso falhar, o cliente irá procurar nos servidores de chaves OpenPGP por uma chave que combine com a impressão digital da assinatura. -# Uma vez adquirida, a chave pública do remetente é armazenada na base de dados localmente encriptada e sincronizada. -# As chaves públicas são atualizadas usando as regras para [[validação de chave transicional => https://leap.se/en/transitional-key-validation]]. - -*Lendo a mensagem* - -O usuário pode ler o email em uma dessas duas maneitas: - -# Conectando um cliente de email, como o Thunderbird, ao servidor IMAP local criado pelo Bitmask. -# Rodando o aplicativo interno do Bitmask (ainda em andamento; não faz parte das versões estáveis atuais). - -h3. Enviando emails - -*Escrevendo uma mensagem* - -O usuário pode escrever um email de uma das seguintes maneiras:: - -# Conectando um agente de usuário de email, como o Thunderbird, ao servidor local SMPT criado pelo Bitmask. -# Lançando a aplicação de correio embutida (opção em andamento, ainda não faz parte da versão estável atual). - -*Encriptando uma mensagem* - -# O gerenciador de chaves do cliente adquire a chave pública de cada destinatário, se ainda não estiver armazenada. -## O gerenciador de chaves vai tentar de todas as formas. Atualmente, isso significa contatar anonimamente o provedor do destinatário e procurar nos servidores de chave OpenPGP, e, no futuro, no servidores DANE/DNSSec e CONIKS. -## As chaves encontradas são armazenadas na base de dados de armazenamento encriptada localmente, e sincronizada com os outros dispositivos do usuário. -# A mensagem é duplicada em cópias separadas, uma para cada destinatário, e cada cópia é encriptada para um destinatário e encaminhada para entrega. - -*Entregando a mensagem* - -Atualmente: - -# O cliente Bitmask se conecta ao servidor MX do provedor do remetente. Esta conexão é autenticada usando um certificado de cliente X.509 armazenado pelo cliente, um para cada um do endereços de email de envio. -# Se o certificado de cliente combina com o campo "De:" do email, então o email é assinado com DKIM e enviado para o servidor MX de destino. - -No futuro (em desenvolvimento): - -# O cliente Bitmask verifica se o destinatário suporta entrega via Panoramix (rede mista anônima). -** Se suportar, o cliente verifica se o remetente tem permissão para fazer a entrega anonimamente para o destinatário (via chaves especiais de entrega). -** Se a permissão de entrega é confirmada, a mensagem será entregue diretamente para o provedor do destinatário usando Panoramix. Neste caso, o provedor do remetente nunca verá o email. -# Se o Panoramix não estiver disponível, o cliente Bitmask se conecta com o servidor MX do provedor do remetente. esta conexão é autenticada usando um certificado de cliente X.509 armazenado pelo cliente, um para cada um dos endereços de envio de email. -# Se o certificado de cliente combina com o campo "De:" do email, então o email é assinado com DKIM e enviado para o servidor MX de destino. - -h2. Limitações - -* Funcionalidades em falta: a versão inicial não suportará aliases de email, encaminhamento de mensagem ou múltiplas contas simultaneamente. -* Você não terá com usar o email Bitmask de um navegador web. O email requer o aplicativo Bitmask para rodar. -* Atualmente, o aplicativo Bitmask requer um provedor compatível. Temos planos de suportar parcialmente provedores comerciais como gmail no futuro. Isso fará com que o usuário fique menos protegido do que se estivesse usando um provedor Bitmask, mas ainda assim iria melhorar bastante a segurança dos seus email. -* Dado que todos os dados são sincronizados, se um usuário tiver um de seus dispositivos comprometidos, então um atacante terá acesso a todos os seus dados. Isto é óbvio, mas vale lembrar. -* O usuário precisa manter uma cópia completa de todos os seus email em cada um dos seus dispositivos. No futuro, planejamos que se possa fazer sincronizações parciais para dispositivos móveis. -* Não estamos planejando a revogação de chaves. Ao invés disso, queremos migrar para chaves temporárias o mais curtas possível. -* Na implementação atual, um provedor de serviços comprometido ou malicioso ainda pode recolher informações que não são encriptadas e metadados sobre o roteamento. Para o futuro, estamos trabalhando em um projeto chamado Panoramix que permitirá que o roteamento da mensagem seja anônimo e que não seja exposto nenhum metadado ao provedor de serviço (somente se o remetente e o destinatário suportarem o Panoramix). -* A encriptação de mensagens por OpenPGP e S/MIME não possuem sigilo futuro (forward secrecy), embora usemos cifras PFS para retransmissão StartTLS. No futuro, esperamos adicionar outras formas de encriptação de mensagem, como o Axolotl. -* Como o nosso esquema atual de validação de chaves, é possível que um provedor possa aceitar uma chave pública falsa por um período de tempo tal que o titular da chave correta não perceba a tramoia. No futuro, esperamos adicionar uma compatibilidade com CONIKS, a qual suporta um histórico de anexação em contínua (cryptographic append-only log) de todas as aceitações de chaves e permita uma auditoria severa das aceitações passadas. - -Para mais detalhes, veja por favor as [[limitações conhecidas => https://leap.se/en/limitations]]. - -h2. Projetos relacionados - -Existem vários outros projetos que trabalham em cima da nova geração dos emails seguros. Na nossa visão, não é possível tornar um email seguro sozinho. Isso requer novos protocolas para lidar com validação de chaves, transporte seguro, e proteção de metadados. Daremos continuidade em nossos esforços para fazer contato com estes grupos e assim buscar áreas de cooperação. - -Para um relatório detalhado de todos os projetos afins, veja https://leap.se/secure-email diff --git a/pages/features/email/ru.text b/pages/features/email/ru.text deleted file mode 100644 index 82d262c..0000000 --- a/pages/features/email/ru.text +++ /dev/null @@ -1,116 +0,0 @@ -@title = "Подробности электронной почты Bitmask" -@nav_title = "Электронная почта" - -h2. Как этим пользоваться - -# Скачайте и установите приложение Bitmask. -# Запустите приложение Bitmask, чтобы авторизоваться или зарегистрироваться на сервис-провайдере. -# Настройте почтовый клиент пользователя для соединения с локальными сервисами IMAP и SMTP, предоставленными приложением Bitmask. В случае работы с почтовым клиентом Thunderbird, эта конфигурация будет полуавтоматической. - -Приложение Bitmask выступает в качестве локального "прокси" между сервис-провайдером и почтовым клиентом. Оно обрабатывает все шифрование и синхронизацию данных. - -h2. Преимущества электронной почты Bitmask - -Возможности электронной почты включают: - -* Зашифрованная почта Bitmask проста в использовании и в то же время обратно совместима с существующими протоколами для безопасной электронной почты (в настоящее время это OpenPGP, с дополнительной поддержкой для S/MIME в будущем). -* Все входящие сообщения, даже если они еще не зашифрованы, автоматически шифруются получателю на сервере перед сохранением, так что только вы можете прочитать их (в том числе мета-данные). Сервер может прочитать незашифрованную входящую почту на мгновение, но никакая почта не хранится когда-либо таким образом, что провайдер может прочесть ее. -* Всякий раз, когда это возможно, исходящая почта автоматически шифруется таким образом, что только получатели могут ее прочесть (если действующие открытые ключи могут быть обнаружены для получателей). Это шифрование происходит на устройстве пользователя. -* Открытые ключи [[автоматически обнаруживаются и подтверждаются => https://leap.se/nicknym]], позволяя вам быть уверенными, что ваша коммуникация является конфиденциальной и с соответствующим человеком (без головной боли типичной подписи ключей) -* Пользователю не нужно беспокоиться об управлении ключами. Их ключи постоянно актуальны на каждом устройстве. -* Пользователь может использовать любой почтовый клиент по своему усмотрению (напр., Thunderbird, Apple Mail, Outlook). -* После отключения от интернета пользователь может по-прежнему взаимодействовать с локальной копией всей своей почты. Когда интернет-соединение снова будет доступно, все изменения синхронизируются с сервером хранения и другими устройствами пользователя. - -Общие характеристики безопасности приложения Bitmask включают: - -* Все данные хранятся в зашифрованном виде, в том числе локальные данные и облачные резервные копии. Шифрование всегда [[происходит на устройстве пользователя => https://leap.se/soledad]], поэтому сервис-провайдер не может читать ваши сохраненные данные. -* Несмотря на то, что вы указываете имя пользователя и пароль для авторизации, [[пароль никогда не передается провайдеру => https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol]]. -* Если вы скачиваете приложение Bitmask с https://dl.bitmask.net, ваш сервис-провайдер не может добавить бэкдор, чтобы скомпрометировать вашу безопасность. -* Приложение Bitmask всегда находится в актуальном состоянии относительно последних патчей безопасности (будет в ближайшее время). - -h2. Как это работает - -ПРИМЕЧАНИЕ: впереди технический жаргон. - -h3. Получение почты - -*Получение и хранение сообщения* - -# Входящая почта получается MX-сервером (mail exchange - обмен почтой) провайдера. -# MX-сервер повторно шифрует входящую почту с помощью открытого ключа получателя. Это происходит, даже если почта уже зашифрована, так что метаданные не хранятся таким образом, что любой кроме получателя может получить к ним доступ. -# Пользователь авторизируется в своем клиенте Bitmask: -## Клиент разблокирует базу данных, зашифрованную локально. -## Клиент спрашивает у сервера, есть ли какие-либо новые данные, и начинает процесс синхронизации. -# Клиент загружает новое входящее сообщение. -# Сообщение расшифровывается с помощью закрытого ключа пользователя, а затем сохраняется в базе данных, зашифрованной локально. -# Локальная база данных синхронизируется с облачной службой хранения провайдера. Для хранения на сервере генерируется уникальный ключ для каждого документа в локальной базе данных перед отправкой на сервер (смотрите [[Soledad => https://leap.se/en/soledad]] для более подробной информации). -# Если у пользователя есть клиент Bitmask, работающий на других устройствах, то эти клиенты заметят изменения в базе данных и выполнят повторную синхронизацию. - -*Проверка сообщения* - -# Если полученное сообщение было подписано, клиент попытается проверять подпись. -# Если открытый ключ отправителя еще неизвестен менеджеру ключей клиента, клиент попытается его приобрести: -## Если сообщение было отправлено с LEAP-совместимого провайдера, ключ будет анонимно запрошен с провайдера отправителя. -## Если открытый ключ прикреплен к сообщению, он будет импортирован. -## Если сообщение содержит заголовок OpenPGP, клиент загрузит открытый ключ из указанного источника. -## Если все остальное не удается, клиент будет искать OpenPGP серверы ключей для ключа, который соответствует отпечатку на подписи. -# После приобретения открытый ключ отправителя хранится в зашифрованной локально и синхронизированной базе данных. -# Открытые ключи обновляются с помощью правил для [[переходной проверки ключей => https://leap.se/en/transitional-key-validation]]. - -*Чтение сообщения* - -Пользователь может читать электронную почту двумя способами: - -# Подключив почтовый агент, такой как Thunderbird, к локальному IMAP-серверу, созданному Bitmask. -# Запустив встроенное почтовое приложение (в процессе, пока не входит в текущие стабильные версии). - -h3. Отправка почты - -*Составление сообщения* - -Пользователь может написать сообщение двумя способами: - -# Одключив почтовый агент, такой как Thunderbird, к локальному SMTP-серверу, созданному Bitmask. -# Запустив встроенное почтовое приложение (в процессе, пока не входит в текущие стабильные версии). - -*Шифрование сообщения* - -# Менеджер ключей клиента приобретает открытый ключ для каждого получателя, если он еще не сохранен. -## Менеджер ключей пытается любыми способами, какими только он может. В настоящее время это включает анонимное контактирование с провайдером получателя и поиск OpenPGP серверов ключей, и будет включать DANE/DNSSec и CONIKS в будущем. -## Обнаруженные ключи сохраняются в локально зашифрованной базе данных и синхронизированы между устройствами пользователя. -# Сообщение дублируется в отдельные копии, по одному для каждого получателя, и каждая копия шифруется для одного получателя и передается для доставки. - -*Передача сообщения* - -В настоящее время: - -# Клиент Bitmask подключается к MX-серверу провайдера отправителя. Это соединение проходит проверку подлинности с использованием сертификата клиента X.509, сохраненного клиентом, отдельно для каждого адреса электронной почты отправителя. -# Если сертификат клиента соответствует полю "От" в сообщении, то электронная почта подписывается DKIM и передается на конечный MX-сервер. - -В будущей (разрабатывается в настоящее время): - -# Клиент Bitmask проверяет, поддерживает ли получатель доставку через Panoramix (анонимную смешанную сеть). -** Если поддерживает, клиент проверяет, есть ли у отправителя разрешение на анонимную доставку получателю (с помощью специальных ключей доставки). -** Если разрешение на доставку предоставлено, сообщение будет доставлено непосредственно провайдеру получателя с помощью Panoramix. В этом случае провайдер отправителя никогда не будет видеть электронную почту. -# Если Panoramix не доступен, клиент Bitmask подключается к MX-серверу провайдера отправителя. Это соединение проходит проверку подлинности с использованием сертификата клиента X.509, сохраненного клиентом, отдельно для каждого адреса электронной почты отправителя. -# Если сертификат клиента соответствует полю "От" в сообщении, то электронная почта подписывается DKIM и передается на конечный MX-сервер. - -h2. Ограничения - -* Отсутствующие возможности: первая версия не будет поддерживать псевдонимы электронной почты, пересылку электронной почты или несколько учетных записей одновременно. -* Вы не можете использовать электронную почту Bitmask из веб-браузера. Нужно, чтобы приложение Bitmask было запущено. -* Приложению Bitmask в настоящее время требуется совместимый провайдер. У нас есть планы в будущем полуподдерживать коммерческих провайдеров, таких как Gmail. Это обеспечило бы пользователю гораздо меньшую защиту, чем в случае использования провайдера Bitmask, но по-прежнему в значительной степени повысило бы безопасность электронной почты. -* Поскольку все данные синхронизируются, если у пользователя одно из его устройств скомпрометировано, то злоумышленник будет иметь доступ ко всем его данным. Это очевидно, но стоит упомянуть. -* Пользователь должен держать полную копию всей электронной переписки на каждом устройстве, которое он использует. В будущем мы планируем поддерживать частичную синхронизацию для мобильных устройств. -* Мы не планируем поддерживать отзыв ключа. Вместо этого мы планируем переходить на все менее и менее живущие ключи, насколько это практически возможно. -* В текущей реализации скомпрометированный или бесчестный сервис-провайдер все еще может собирать входящие сообщения, которые не зашифрованы, и мета-данные информации о маршрутизации. В перспективе, мы работаем над проектом под названием Panoramix, который позволит маршрутизацию сообщений, которая будет анонимной и не будет раскрывать никакую информацию о мета-данных сервис-провайдеру (до тех пор пока отправитель и получатель поддерживают Panoramix). -* OpenPGP и S/MIME-шифрование сообщений не имеет прямой секретности, хотя мы используем PFS шифры для StartTLS передачи. В будущем мы надеемся добавить дополнительные формы шифрования сообщений, такие как Axolotl. -* С нашей нынешней схемой автоматической проверки ключей, есть шанс, что провайдер может одобрить поддельный открытый ключ в течение короткого промежутка времени так, что владелец правильного ключа не заметит уловки. В будущем мы надеемся добавить совместимость с CONIKS, который поддерживает криптографический журнал только на добавление всех согласований ключей и дает возможность сильного аудита этих прошедших согласований. - -Для более подробной информации смотрите [[известные ограничения => https://leap.se/en/limitations]]. - -h2. Похожие проекты - -Существуют множество других проектов, работающих над следующим поколением безопасной электронной почты. На наш взгляд, невозможно сделать безопасной электронную почту в одиночку, необходимы новые протоколы для передачи проверки ключей, безопасной транспортировки и защиты мета-данных. Мы продолжим наши усилия для достижения этих групп для того, чтобы исследовать направления сотрудничества. - -Для подробного отчета о всех связанных проектах, смортите https://leap.se/secure-email.
\ No newline at end of file diff --git a/pages/features/en.haml b/pages/features/en.haml index c1eb95b..8c956d1 100644 --- a/pages/features/en.haml +++ b/pages/features/en.haml @@ -19,23 +19,6 @@ <b>Extra Security</b><br> We take extra security measures to prevent problems common to other personal VPNs, such as DNS leakage and IPv6 leakage. -%h1#email Email features - -%p Bitmask Encrypted Email is easy to use while still being backward compatible with the existing OpenPGP protocol for secure email. - -%ul.fa-ul.spaced - %li - %i.fa-li.fa.fa-check-square - <b>Full end-to-end encryption</b><br> - Whenever possible, all messages are encrypted end-to-end on the client device. - %li - %i.fa-li.fa.fa-check-square - <b>Secure Storage</b><br> - All incoming email is automatically encrypted so only you can read it (including meta-data). - %li - %i.fa-li.fa.fa-check-square - <b>Automatic Key Management</b><br> - The user never needs to know or worry about generating keys, discovering keys, or validating keys. %h1 Security features @@ -44,23 +27,28 @@ .col-sm-6 %ul.fa-ul.spaced %li - %i.fa-li.fa.fa-save - <b>Client-encrypted Storage</b><br> - All data storage is encrypted, including local data and cloud backups. This encryption always [[takes place on your device => https://leap.se/en/soledad]], so the service provider cannot read your stored data. - %li - %i.fa-li.fa.fa-exchange - <b>Always Available</b><br> - Your data is always available, even when you are offline, it is [[synchronized to the devices => https://leap.se/en/soledad]] you choose, and secured backed up to the cloud. + %i.fa-li.fa.fa-exclamation-circle + <b>Allows anonymous usage</b><br> + LEAP providers can enable the VPN usage using a anonymous certificate as verification method. No Passwords needed! %li %i.fa-li.fa.fa-exclamation-circle <b>Passwords, Improved</b><br> 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]]. + %li + %i.fa-li.fa.fa-exclamation-circle + <b>Pluggable Transports</b><br> + Bitmask Android supports Pluggable Transports to circumvent VPN blockings. + %li + %i.fa-li.fa.fa-exclamation-circle + <b>Firewall</b><br> + RiseupVPN, the branded version of Bitmask for desktops supports extra firewalling to prevent data leakage (currently Linux and MacOSX, Windows coming soon). + .col-sm-6 %ul.fa-ul.spaced %li %i.fa-li.fa.fa-clock-o <b>Up to date</b><br> - The Bitmask application is always kept up to date with the latest security patches (coming soon). + The Bitmask application is always kept up to date with the latest security patches for Android and Linux. Windows and Mac users currently need to update manually, but we're working on automatic update mechanisms there as well. %li %i.fa-li.fa.fa-institution <b>Don't trust the provider</b><br> diff --git a/pages/features/es.haml b/pages/features/es.haml index 6e10490..119e3e1 100644 --- a/pages/features/es.haml +++ b/pages/features/es.haml @@ -19,24 +19,6 @@ <b>Seguridad Extra</b><br> Tomamos algunas medidas extra de seguridad para evitar problemas comunes a otras aplicaciones de VPN, tales como filtración de DNS o filtrado IPv6. -%h1#email Correo Electrónico Cifrado - -%p El Mail Cifrado de Bitmask es fácil de usar, permaneciendo compatible con el protocolo OpenPGP existente para correo electrónico seguro. - -%ul.fa-ul.spaced - %li - %i.fa-li.fa.fa-check-square - <b>Cifrado completo de principio a fin</b><br> - Siempre que resulte posible, todos los mensajes se cifran de un extremo a otro en el dispositivo cliente. - %li - %i.fa-li.fa.fa-check-square - <b>Almacenamiento Seguro</b><br> - Todo el correo electrónico entrante es cifrado automáticamente, de modo que sólo tú puedes leerlo (incluyendo los metadatos). - %li - %i.fa-li.fa.fa-check-square - <b>Gestión Automática de Claves</b><br> - El usuario nunca necesita saber acerca de, o preocuparse, sobre la generación, descubrimiento o validación de claves. - %h1 Seguridad @@ -44,14 +26,6 @@ .col-sm-6 %ul.fa-ul.spaced %li - %i.fa-li.fa.fa-save - <b>Almacenamiento Cifrado en el Cliente</b><br> - Todo el almacenamiento de datos está cifrado, incluyendo tanto tus datos locales como los backups en la nube. Este cifrado siempre [[tiene lugar en tu dispositivo => https://leap.se/es/soledad]], de forma que tu proveedor no puede leer los datos que almacenas. - %li - %i.fa-li.fa.fa-exchange - <b>Siempre Disponible</b><br> - Tus datos están siempre disponibles, incluso cuando estás desconectado, [[sincronizados con los dispositivos => https://leap.se/es/soledad]] de tu elección y replicados en la nube. - %li %i.fa-li.fa.fa-exclamation-circle <b>Contraseñas, Mejoradas</b><br> A pesar de que especificas un nombre de usuario y una contraseña para loguearte, tu [[contraseña nunca viaja al proveedor => https://es.wikipedia.org/wiki/Secure_Remote_Password]]. @@ -60,7 +34,7 @@ %li %i.fa-li.fa.fa-clock-o <b>Siempre Actualizado</b><br> - La aplicación Bitmask va a mantenerse siempre actualizada con los últimos parches de seguridad (muy pronto). + La aplicación Bitmask va a mantenerse siempre actualizada con los últimos parches de seguridad para Android y Linux. En Windows y Mac actualmente es necesario actualizar manualmente, pero estamos trabajando en mecanismos de actualización automática también. %li %i.fa-li.fa.fa-institution <b>No te fies de tu proveedor</b><br> diff --git a/pages/features/pt.haml b/pages/features/pt.haml index 77f3c90..079643a 100644 --- a/pages/features/pt.haml +++ b/pages/features/pt.haml @@ -19,39 +19,12 @@ <b>Segurança Extra</b><br> Tomamos medidas extras de segurança para evitar problemas comuns a outras VPNs pessoais, tais como vazamento de DNS ou de IPv6. -%h1#email Email - -%p O Email Encriptado Bitmask é fácil de usar ao mesmo tempo que continua compatível com o protocolo OpenPGP existente para email seguro. - -%ul.fa-ul.spaced - %li - %i.fa-li.fa.fa-check-square - <b>Encriptação de ponta-a-ponta total</b><br> - Sempre que possível, todas as mensagens são encriptadas ponta-a-ponta no dispositivo cliente. - %li - %i.fa-li.fa.fa-check-square - <b>Armazenamento Seguro</b><br> - Todos os emails que chegam são automaticamente encriptados, de modo que só você pode lê-los (incluindo os metadados). - %li - %i.fa-li.fa.fa-check-square - <b>Gestão Automática de Chaves</b><br> - O usuário nunca precisa saber ou se preocupar com a geração, o descobrimento, ou a validação de chaves. - - %h1 Características de Segurança .row .col-sm-6 %ul.fa-ul.spaced %li - %i.fa-li.fa.fa-save - <b>Armazenamento Encriptado no Cliente</b><br> - Todos os dados armazenados são encriptados, incluindo dados locais e backups da nuvem. Esta encriptação sempre [[acontece no seu dispositivo => https://leap.se/en/soledad]], para que assim o provedor de serviço não possa ler seus dados armazenados. - %li - %i.fa-li.fa.fa-exchange - <b>Sempre Disponível</b><br> - Seus dados estão sempre disponíveis, mesmo quando você estiver desconectado. Eles são [[sincronizados com os dispositivos => https://leap.se/en/soledad]] que você escolher e replicados de forma segura na nuvem. - %li %i.fa-li.fa.fa-exclamation-circle <b>Senhas, Melhoradas</b><br> Apesar de você especificar um usuário e senha para logar, sua [[senha nunca é mandada para o provedor => https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol]]. @@ -60,7 +33,7 @@ %li %i.fa-li.fa.fa-clock-o <b>Atualizada</b><br> - O Bitmask está sempre atualizado com os mais recentes patches de segurança (em breve). + O Bitmask está sempre atualizado com os mais recentes patches de segurança para Android e Linux. %li %i.fa-li.fa.fa-institution <b>Não confie no provedor</b><br> diff --git a/pages/features/ru.haml b/pages/features/ru.haml index 839d24d..2237bcd 100644 --- a/pages/features/ru.haml +++ b/pages/features/ru.haml @@ -44,14 +44,6 @@ .col-sm-6
%ul.fa-ul.spaced
%li
- %i.fa-li.fa.fa-save
- <b>Хранение с шифрованием на стороне клиента</b><br>
- Хранение всех данных зашифровано, в том числе локальных и облачных резервных копий. Шифрование всегда [[происходит на устройстве => https://leap.se/en/soledad]], поэтому сервис-провайдер не сможет прочесть ваши сохраненные данные.
- %li
- %i.fa-li.fa.fa-exchange
- <b>Постоянная доступность</b><br>
- Ваши данные всегда доступны, даже когда вы находитесь оффлайн, они [[синхронизируются с устройствами => https://leap.se/en/soledad]], которые вы выбираете, и безопасно резервируются на облаке.
- %li
%i.fa-li.fa.fa-exclamation-circle
<b>Усовершенствованные пароли</b><br>
Несмотря на то, что вы указываете имя пользователя и пароль для авторизации, ваш [[пароль никогда не сообщается провайдеру => https://en.wikipedia.org/wiki/Secure_Remote_Password_protocol]].
@@ -60,7 +52,7 @@ %li
%i.fa-li.fa.fa-clock-o
<b>Актуальность</b><br>
- Приложение Bitmask всегда находится в актуальном состоянии относительно последних патчей безопасности (скоро выйдут).
+ Приложение Bitmask всегда находится в актуальном состоянии относительно последних патчей безопасности (Linux и Android). Пользователям Windows и Mac необходимо обновлять вручную, но мы также работаем над автоматическими механизмами обновления там.
%li
%i.fa-li.fa.fa-institution
<b>Не доверяйте провайдеру</b><br>
diff --git a/pages/features/vpn/ru.text b/pages/features/vpn/ru.text index ca09502..65eb726 100644 --- a/pages/features/vpn/ru.text +++ b/pages/features/vpn/ru.text @@ -107,4 +107,4 @@ h1. Ограничения VPN * *Интернет может быть медленнее*: Bitmask VPN перенаправляет весь ваш трафик через зашифрованное соединение к выбранному вами провайдеру, прежде чем он выходит в обычный интернет. Этот дополнительный шаг может замедлить ход событий. Чтобы свести к минимуму замедление, попробуйте выбрать сервер VPN-шлюза поближе к месту, где вы на самом деле живете. -* *Анонимные прокси-серверы*: Некоторые сайты блокируют доступ с "анонимных прокси-серверов". По этой причине, в зависимости от того, какой VPN-шлюз вы используете, ваш трафик может быть заблокирован.
\ No newline at end of file +* *Анонимные прокси-серверы*: Некоторые сайты блокируют доступ с "анонимных прокси-серверов". По этой причине, в зависимости от того, какой VPN-шлюз вы используете, ваш трафик может быть заблокирован. |