Friday, August 30, 2019

Added a new VPN server in United States, Dallas (US4)

Added new configuration files with US4 server:


The server is available as a single to connect and as an incoming in a dual connection.
An outgoing connection in a double circuit will be available later.


Добавлен новый VPN сервер в США, Даллас (US4)


Сервер доступен как одиночный для подключения и как входящий в двойном подключении.
Исходящее подключение в двойной цепи будет доступно позже.

Thursday, August 29, 2019

Added a new VPN server in United States, Chicago (US3)

Added new configuration files with US3 server:


The server is available as a single to connect and as an incoming in a dual connection.
An outgoing connection in a double circuit will be available later.


Добавлен новый VPN сервер в США, Чикаго (US3)


Сервер доступен как одиночный для подключения и как входящий в двойном подключении.
Исходящее подключение в двойной цепи будет доступно позже.

Monday, August 26, 2019

Changing the principle of the canary

The MultiVPN service canary was launched on November 22, 2018.
Read about this event here:

Read more about this service here:

Today, we are changing the principle of the canary to a more perfect one.
Previously, it was necessary to sign a test file with relevant information, a GPG key, which only the service administrator has. In case of outdated information - the canary was dying.

In the updated version of the canary, everything you need is built into the HTTP header of the main domain of the service:

In order to exclude the possibility of falsifying the DNS query of the main domain, we use the DNSSEC signature on our DNS servers and this makes it difficult to use the fake canary and the site as a whole.
In the whois domain request, it looks like this:
DNSSEC: signedDelegation

Read more about DNSSEC here:

Continuing the topic of data protection, we use TLS certificates, only from LetsEncrypt, other publishers of TLS certificates are forbidden to issue them, this is evidenced by the DNS record of our domain’s CA:
policy host:
iodef: mailto: flags: 0
issue: flags: 0

Read more about DNS CA here:

Since there are always unscrupulous publishers, under the pressure of special services or other circumstances, fake TLS certificates can be issued for conducting human attacks in the middle.

To exclude this possibility, we added HSTS technology ( paired with HPKP ( to force binding your browser to our encryption keys on the side of the web server.

Of course, only the administration of the service has access to the encryption keys specified in HPKP and the web server works with full-disk encryption of the file system to exclude the possibility of hijacking keys by a hosting or other service.

Unfortunately, some developers of non-traditional sexual orientation, from large corporations that engage in mass surveillance on the Internet, under the pressure of secret services, remove support for this technology in their browsers:

However, at the moment, it’s absolutely known that the support of HPKP technology is provided by the Opera ( and IceCat ( browsers. We recommend using it to work with our service.

All this is organized in order to minimize the possibility attack for our customers.

Returning to the topic of canaries. Now, data for clients reporting the current status of the canary will be transmitted in the server’s HTTP headers on the main domain of the service:

What does it look like:
Canary date = 08/26/2019; linkone =; linktwo =;

In this HTTP header called "Canary", several parameters are passed:
date = 08/26/2019; - date of updating the canary, in the format day.month.year.
In this example, the canary was updated on August 26, 2019.
Second header parameter:
linkone =;
this is the first link to a YouTube video released at about the same time as the canary was published.
Third header parameter:
linktwo =;
a backup link to a YouTube video if the first video is unavailable.
Thus, it becomes clear that the date of publication of the video should approximately correspond to the time of publication of the canary, and not just contain fictitious publication dates.

If the canary update date exceeds 1 calendar month, as in the above example, at the end of September or even in October, the canary was not updated, this is a sign of pressure on the administration of the service by law enforcement agencies and other. Coercion to cooperate with the investigation, etc. What should listen to the signal, for our customers that the service may no longer be the same as before.

Information for law enforcement agencies: we are not going to give out information about our customers.
In the case of any pressure on the administration of the service, it is more likely that the right person for the investigation will stop using our service and all actions will be in vain.

“Canary evidence” is a method of transmitting information through silence or denial. According to the Patriotic Act, the US government can send a secret warrant to the provider to monitor the user. The law prohibits companies from divulging the fact of the existence of such an order, but the company can circumvent this ban without violating the law: the company can notify the user that it was not secretly monitored at a certain point - such a phrase may be indicated in some report company user. If the company received a warrant, there will be no such notice in the report. "

Article 23 of the Constitution of the Russian Federation:
1. Everyone has the right to privacy, personal and family secrets, protection of his honor and good name.
2. Everyone has the right to privacy of correspondence, telephone conversations, postal, telegraphic and other communications. The restriction of this right is allowed only on the basis of a court decision.

How to read the "Canary" header in the HTTP server header? (HTTP Requests section)

and other similar services.


Изменение принципа работы канарейки

Канарейка сервиса MultiVPN была запущена 22 ноября 2018 года.
Прочитать об этом событии можно здесь:

Подробнее прочитать о данном сервисе можно здесь:Свидетельство_канарейки

Сегодня, мы меняем принцип работы канарейки на более совершенный.
Ранее, необходимо было подписывать тестовый файл с актуальной информацией, GPG ключем, который есть только у администратора сервиса. В случае устаревания информации - канарейка умирала.

В обновленной версии канарейки, всё необходимое встроено в HTTP заголовок главного домена сервиса:

Что бы исключить возможность подделки DNS запроса главного домена, мы используем подпись DNSSEC на наших серверах DNS и это затрудняет использование фейка канарейки и сайта в целом.
В whois запросе домена это выглядит так:
DNSSEC: signedDelegation

Подробнее прочитать о DNSSEC можно здесь:

В продолжении темы защиты данных, мы используем TLS сертификаты, только от LetsEncrypt, остальным издателям TLS сертификатов, запрещено выпускать их, об этом свидетельствует DNS запись CA нашего домена:
policy host:
iodef: flags:0
issue: flags:0

Подробнее почитать о DNS CA можно здесь:

Поскольку, всегда находятся недобросовестные издатели, под давлением спецслужб или иных обстоятельств, могут быть выпущены поддельные TLS сертификаты для проведения атак человек по середине.

Что бы исключить и эту возможность, мы добавили технологию HSTS ( в паре с HPKP ( для принудительной привязки Вашего браузера к нашим ключам шифрования на стороне вебсервера.

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

К сожалению, некоторые разработчики нетрадиционной сексуальной ориентации, из крупных корпораций, которые занимаются массовой слежной в Интернете, под давлением секретных служб, удаляют поддержку данной технологии в своих браузерах:

Однако, на данный момент, абсолютно точно известно что поддержку технологии HPKP осуществляют браузеры Opera ( и IceCat (, именно эти браузеры рекомендуем использовать для работы с нашим сервисом.

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

Возвращаясь к теме канарейки. Теперь, данные для клиентов, сообщающие о текущем состоянии канарейки, будут передаваться в HTTP заголовках сервера на главном домене сервиса:

Как это выглядит:
Canary    date=26.08.2019; linkone=; linktwo=;

В данном HTTP заголовке с названием "Canary", передается несколько параметров:
date=26.08.2019; - дата обновления канарейки, в формате день.месяц.год.
В данном примере канарейка была обновлена 26 августа 2019 года.
Второй параметр заголовка:
это первая ссылка на видео YouTube выпущенное в примерно то-же время что и публиковалась канарейка.
Третий параметр заголовка:
запасная ссылка на видео YouTube, в случае недоступности первого видео.
Таким образом становится понятно, что дата публикации видео, должна примерно соответствовать времени публикации канарейки, а не просто содержать выдуманные даты публикации.

Если дата обновления канарейки превышает 1 календарный месяц, как в указанном примере выше, в конце сентября или даже в октябре, канарейка не была обновлена, это является признаком об оказании давления на администрацию сервиса со стороны силовых структур и других органов. Принуждение к сотрудничеству со следствием и т.д. Что должно послушить сигналом, для наших клиентов о том, что сервис может уже не быть таким, как прежде.

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

"Свидетельство канарейки" - способ передачи информации, осуществляемый через молчание или отрицание. Согласно "Патриотическому акту", правительство США может направить секретный ордер провайдеру на слежку за пользователем. Закон запрещает компании разглашать факт существования подобного ордера, однако компания может обойти этот запрет, не нарушив при этом закона: компания может уведомлять пользователя о том, что за ним в определённый момент не велось скрытого наблюдения — подобная фраза может быть указана в каком-либо отчёте компании пользователю. Если же компания получила ордер, такого уведомления в отчёте не будет."

Статья 23 конституции Российской Федерации:
1. Каждый имеет право на неприкосновенность частной жизни, личную и семейную тайну, защиту своей чести и доброго имени.
2. Каждый имеет право на тайну переписки, телефонных переговоров, почтовых, телеграфных и иных сообщений. Ограничение этого права допускается только на основании судебного решения.

Как прочитать заголовок "Canary" в HTTP заголовке сервера? (раздел HTTP Requests)

и другие подобные сервисы.

Friday, August 16, 2019

Personal Account Template Integration

Replaced the template of your personal account. Now, the user's personal account is more similar to the main site design than before.
Quadratisch, praktisch, gut. You can order a similar service here:

Thanks for the work you've done. Pleasing to the eye ;-)


Интеграция шаблона личного кабинета

Произведена замена шаблона личного кабинета. Теперь, личный кабинет пользователя более похож на основной дизайн сайта, чем ранее.
Дёшево, быстро, сердито. Заказать подобную услугу можно здесь:

Спасибо за проделанную работу. Радует глаз ;-)

Elliptic curve secp384r1 instead of secp256k1

For a long time, we used the secp256k1 curve (as on the Bitcoin network) to connect to the OpenVPN server using elliptical cryptography. And it works well.

Control Channel: TLSv1.2, cipher TLSv1 / SSLv3 ECDHE-ECDSA-AES256-GCM-SHA384, 256 bit EC, curve: secp256k1

However, some software in the OpenSSL and OpenVPN bundle have compatibility issues.
Unfortunately secp256k1 is not supported by all OpenVPN clients by default.

The solution was found in replacing the elliptic curve with secp384r1.
This curve is supplied in many products: browsers, TLS, OpenSSL, LibreSSL and others.
Compatibility is much higher than before, and most importantly, cryptographic strength is higher!

As indicated above, in the comparison table, 256 ECC bits is the equivalent of 3072 bits of the RSA key and AES 128 bits of the symmetric encryption key.
The new secp384r1 curve used is 7680 bits for the RSA key. That allows it to be used to encrypt documents classified as "top secret."

All service clients using elliptical cryptography should update the configuration files.
You can download them at the link (ECC):

In the OpenVPN connection log, the new curve looks like this:
Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 384 bit EC, curve: secp384r1


Эллиптическая кривая secp384r1 вместо secp256k1

Долгое время мы использовали кривую secp256k1 (как в сети Bitcoin) для подключения к OpenVPN серверу используя эллиптическую криптографию. И это хорошо работает.

Control Channel: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-ECDSA-AES256-GCM-SHA384, 256 bit EC, curve: secp256k1

Однако, есть проблемы с совместимостью у некоторого программного обеспечения в связке OpenSSL и OpenVPN.
К сожалению secp256k1 поддерживается далеко не всеми OpenVPN клиентами по умолчанию.

Выход был найден в замене эллиптической кривой на secp384r1.
Данная кривая поставляется во многих продуктах: браузерах, подключении TLS, OpenSSL, LibreSSL и других.
Совместимость гораздо выше чем раньше, и самое главное - криптографическая стойкость - выше!

Как указано выше, в сравнительной таблице, 256 бит ECC является эквивалентом 3072 бит RSA ключа и AES 128 бит ключа симметричного шифрования.
Новая используемая кривая secp384r1 равняется 7680 бит ключу RSA. Что позволяет её использовать для шифрования документов с грифом "совершенно секретно".

Всем клиентам сервиса использующим эллиптическую криптографию, следует обновить файлы конфигурации.
Скачать их можно по ссылке (ECC):

В логе подключения OpenVPN, новая кривая выклядит так:
Control Channel: TLSv1.2, cipher TLSv1.2 ECDHE-ECDSA-AES256-GCM-SHA384, 384 bit EC, curve: secp384r1

August jetpack update: 4 new servers

During this month, 4 new servers were added to increase throughput in the most loaded areas of the service:

Netherlands, Amsterdam (NL1A)
Russia, Moscow (RU1A)
Russia, St. Petersburg (RU2A)
Sweden, Stockholm (SE1A)

These servers are already working on the network and are available for connection.
Please update the configuration files to use them.


Август джетпак-обновление: 4 новых сервера

В течении этого месяца добавлены 4 новых сервера для увеличения пропускной способности на самых нагруженных направлениях сервиса:

Нидерланды, Амстердам (NL1A)
Россия, Москва (RU1A)
Россия, Санкт-Петербург (RU2A)
Швеция, Стокгольм (SE1A)

Данные серверы уже работают в сети и доступны для подключения.
Пожалуйста, обновите файлы конфигурации что бы воспользоваться ими.

Monday, August 5, 2019

Added IPv6 support for service site and aliases

Now the site of the service and its aliases are available via IPv6.
IPv6 distribution map:
IPv6 usage statistics:
Keep up with the times ;-)


Добавленая поддержка IPv6 для сайта сервиса и алиасов

Теперь сайт сервиса и его алиасы доступны через IPv6.
Карта распространения IPv6:
Статистика использования IPv6:
Идём в ногу со временем ;-)

Reviews on are more dead than alive

February 19 was added news about the service reviews and suggestions from
For all the past time, no one used it.
This project can be called failed.
Domain deleted, scripts cut.


Отзывы на скорее мёртвы, чем живы

19 февраля была добавлена новость о сервисе отзывов и предложений от
За всё прошедшее время, им никто не воспользовался.
Данный проект можно назвать несостоявшимся.
Домен удалён, скрипты вырезаны.