Как происходит Авторизация через HTTPS в Wordpress ?

При этом, считается, что шифрованное соединение сильно грузит сервер.

Не сильно.

Есть идея использовать плагин

http://codex.wordpress.org/Administration_Over_SSL

В современных реалиях SSL не нагружает. Да и вообще, делай редирект с http на https сервером.

Т.е. получается, что данные с этих страниц не шифруются ?!

А какаие там данные? Форма авторизации в html? Эти данные и так любому доступны) Главное непосредственно пароль и логин шифровать которые запросом передаются серверу.

Страница с формой грузится по http, из нее посылается запрос на https.

Форма авторизации в html?

И адрес куда POSTится логин и пароль. Человек-посередине может быть и активным.

Страница с формой грузится по http, из нее посылается запрос на https.

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

<div class="left-box">

	<form action="https://mydomain.org/vhid/" method="post" class="loginform" id="login-form">
		
	<p>
	<label for="login_username">Имя пользователя:</label>
	<input type="text" class="text required" name="log" id="login_username" value="" />
	</p>

	<p>
	<label for="login_password">Пароль:</label>
	<input type="password" class="text required" name="pwd" id="login_password" value="" />
	</p>

	<div class="clr"></div>

	<div id="checksave">

	<p class="rememberme">
	<input name="rememberme" class="checkbox" id="rememberme" value="forever" type="checkbox" checked="checked" />
	<label for="rememberme">Запомнить меня на этом компьютере</label>
	</p>

	<p class="submit">
	<input type="submit" class="btn_orange" name="login" id="login" value="ВХОД &raquo;" />
	<input type="hidden" name="redirect_to" value="http://mydomain.org" />	<input type="hidden" name="testcookie" value="1" />
	</p>

	<p class="lostpass">
	<a class="lostpass" href="https://mydomain.org/obnovlenie-parolya/" title="Сброс пароля">Забыли пароль?</a>
	</p>

	<p class="register"><a href="https://mydomain.org/zaregestrirovatsa/?redirect_to=http%3A%2F%2Fmydomain.org">Регистрация</a></p>
								
</div>

Ты http://codex.wordpress.org/Administration_Over_SSL прочитал уже?

Имеет ли это значение?

Имеет в части «кроме ссылки во второй строке этого кода», т.к. это именно адрес для аутентификации, т.е. сообщение будет передано по зашифрованному каналу.

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

Как вордпресс должен определять конфиденциальные ли данные передаются?

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

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

И да, ты, похоже, решил, что после того, как кука передана клиенту, сервер телепатически идентифицирует клиента (ну куку-то мы ему передали). Эта кука передается с каждым запросом обратно, именно так сервер идентифицирует клиента.

Ты http://codex.wordpress.org/Administration_Over_SSL прочитал уже?

Канэшна :)
С английским у меня плохо и я не увидел там ответа на заданные мной вопросы.
Может приведете цитаты?
Сервер настроен, wp-login и wp-admin TRUE в wp-config.php прописаны. Админка сайта полностью работает в https.
Вот заставить страницу авторизации и регистрации грузится в первый раз по https без вышеназванного плагина не удалось, но как говорят мне здесь - это не нужно.
Что еще упустил?

это не нужно
В сети опубликованы 2 пароля от учетных записей на сервере san-sanych.

И да, ты, похоже, решил, что после того, как кука передана клиенту, сервер телепатически идентифицирует клиента (ну куку-то мы ему передали). Эта кука передается с каждым запросом обратно, именно так сервер идентифицирует клиента.

Мдя. Значит дальнейшее поддержание https имеет значение для того, чтобы сохранить эту куку в тайне. Так?
В файле wp-config.php есть такой вот раздельчик:

/**#@+
 * Уникальные ключи и соли для аутентификации.
 *
 * Смените значение каждой константы на уникальную фразу.
 * Можно сгенерировать их с помощью {@link https://api.wordpress.org/secret-key/1.1/salt/ сервиса ключей на WordPress.org}
 * Можно изменить их, чтобы сделать существующие файлы cookies недействительными. Пользователям потребуется снова авторизоваться.
 *
 * @since 2.6.0
 */
define('AUTH_KEY',         'впишите сюда уникальную фразу');
define('SECURE_AUTH_KEY',  'впишите сюда уникальную фразу');
define('LOGGED_IN_KEY',    'впишите сюда уникальную фразу');
define('NONCE_KEY',        'впишите сюда уникальную фразу');
define('AUTH_SALT',        'впишите сюда уникальную фразу');
define('SECURE_AUTH_SALT', 'впишите сюда уникальную фразу');
define('LOGGED_IN_SALT',   'впишите сюда уникальную фразу');
define('NONCE_SALT',       'впишите сюда уникальную фразу');

/**#@-*/

В сети опубликованы 2 пароля от учетных записей на сервере san-sanych.

О чем речь? Где в сети опубликованы пароли моей учетной записи?

Это используется для генерации кук. Третьему лицу не нужно ничего вычленять. Он просто берет куку и передает ее серверу. Сервер по куке определяет пользователя (жерта ли это или злоумышленник, не важно). Все.
Слушай, чувак, я ваще не знаю этого твоего вордпресса, так работают все сайты. Те, которые так не работают, скорее всего не работают совсем. Тебе не нужно придумывать ничего нового, просто делай как сказано в документации. Когда некомпетентный человек пытается изобрести очередную суперсукурную фундервафлю, то случается гарантированный фейл. Сто раз уже проходили. Капча 100 подтверждает.

Это используется для генерации кук.

Все ясно - после авторизации, для поддержания секьюрности, соединение с сервером должно оставаться зашифрованным.
Спасибо всем ответившим.

Что там про пароли san-sanych?

Неудачная шутка в свете последних событий, связанных с yandex, mail.ru, и google.

Неудачная шутка в свете последних событий, связанных с yandex, mail.ru, и google

Дело в том, что я один раз менял пароль san-sanych и в природе их существует именно два - старый и новый. Непохоже на шутку.

Что еще упустил?
define('FORCE_SSL_ADMIN', true);

Если не поможет, то пункт

Rewrite Rules For The Insecure Host

И адрес куда POSTится логин и пароль. Человек-посередине может быть и активным.

Этот адрес и так можно посмотреть зайдя на сайт и нажав кнопку «авторизация»

Смпециально-же написал что может существовать активный посредник. Подменяешь адрес куда отправляется пароль на свой собственный (или просто заменяешь https на http) и невозбранно получаешь пароль.

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

Если по хорошему, то да. Но если защитить нужно в основном пароль админа или контент-менеджера то можно просто привыкнуть проверять глазами какой там протокол сейчас.
В случае когда по https только постятся данные авторизации посмотреть глазами какой используется протокол просто негде.

Есть какой-то стандарт (забыл название) позволяющий серверу указать клиенту можно-ли заходить на этот сайт по http, или только по https (суть в том что-бы браузер, вместо человека, помнил что на этот сайт можно ходить только по https). Может он позволяет и для отдельных урлов политики задавать.