# HTTPS: titkosított kapcsolat a webhelyeden

> Miért érdemes HTTPS-t használni, hogyan kényszerítheted ki a titkosított bejelentkezést és adminfelületet, és mit tegyél fordított proxy mögött.

A HTTPS a weboldalak titkosított kommunikációs módja. A böngésződ és a webszerver között privát csatorna jön létre, ezért a legtöbb nagy webhely ezt használja. Ha egy oldal HTTPS-en fut, a böngésző címsorában egy kis lakat ikont látsz.

## Miért érdemes HTTPS-t használni?

- **Gyorsabb.** Elsőre furcsa, de a HTTP számos sebességnövelő fejlesztése csak HTTPS-en érhető el, ezért a legtöbb látogatónak a webhelyed valójában gyorsabban töltődik be.
- **Bizalom.** A látogatók könnyebben bíznak egy védett oldalban. A lakat ikon azt üzeni, hogy az oldal gondol az adatvédelemre. Aki érti a hátterét, azt is tudja, hogy a böngésző és a szerver közti köztes gépek nem látják és nem módosíthatják az áthaladó adatokat.
- **Fizetési biztonság.** Ha bármit árulsz a webhelyeden, a vásárlók tudni akarják, hogy a fizetési adataik biztonságban jutnak el a szerverig. A HTTPS és a lakat ezt jelzi.
- **Keresőoptimalizálás.** Sok keresőmotor hátrébb sorolja a HTTPS nélküli webhelyeket, ezért nehezebb a legjobb helyekre kerülni a találatok között.
- **A jó híred.** A böngészők a HTTPS nélküli oldalak mellé kiírják, hogy „nem biztonságos”. Ezzel azt üzenik, hogy az a webhelytulajdonos, aki nem foglalkozik a titkosítással (sok helyen ingyenes), nem érdemel bizalmat. Nem szeretnéd, hogy a böngésző téged is ilyennek mutasson.

A WordPress teljes mértékben kompatibilis a HTTPS-sel, ha a webszerveren telepítve van egy TLS/SSL tanúsítvány. A HTTPS használata határozottan ajánlott, mert védi a WordPress-bejelentkezéseket és a látogatókat is.

## Az adminfelület HTTPS-en

A WordPress-adminfelület titkosításához és kikényszerítéséhez egy konstanst kell megadnod a webhely `wp-config.php` fájljában.

> **Figyelem**
>
> A konstansnak a `wp-config.php` fájlban kell szerepelnie, bővítményfájlban megadva nem elég. A beállítás előtt a szerveren már működnie kell az SSL-nek, és a biztonságos szerverhez tartoznia kell egy (virtuális) hosztnak. Ha ezek hiányoznak, a webhely nem működik rendesen a konstans bekapcsolása után. Ha nem vagy biztos benne, kérj segítséget a tárhelyszolgáltatódtól.

### HTTPS-bejelentkezés és HTTPS-adminhozzáférés kikényszerítése

Ha a `FORCE_SSL_ADMIN` konstanst `true` értékre állítod, minden bejelentkezés és minden adminmunkamenet SSL-en fut.

```php
define( 'FORCE_SSL_ADMIN', true );
```

A korábbi `FORCE_SSL_LOGIN` konstans elavult, helyette a `FORCE_SSL_ADMIN` használható.

### Fordított proxy (reverse proxy) mögött

Előfordul, hogy a WordPress egy fordított proxy mögött fut. A proxy biztosítja az SSL-t, de maga a WordPress SSL nélkül áll. Ilyenkor a fenti beállítás végtelen átirányítási hurokba küldi a kéréseket. Ennek elkerülésére be kell állítanod, hogy a WordPress ismerje fel a `HTTP_X_FORWARDED_PROTO` fejlécet. Ez csak akkor működik, ha a proxy ezt a fejlécet megfelelően beállítja.

```php
define( 'FORCE_SSL_ADMIN', true );
// Egyes beállításoknál a HTTP_X_FORWARDED_PROTO értéke vesszővel
// elválasztott lista lehet, pl. http,https, ezért a https meglétét keressük.
if ( strpos( $_SERVER['HTTP_X_FORWARDED_PROTO'], 'https' ) !== false ) {
    $_SERVER['HTTPS'] = 'on';
}
```

Proxy-átirányításnál a kérést egy másik géphez továbbítod, de a hozzá tartozó fejlécek nem mennek vele automatikusan. A WordPressnek viszont szüksége van néhányra a helyes átirányításokhoz, ezért az átirányítási szabályba fel kell venned őket. Nginx esetén például így:

```nginx
location / {
    proxy_pass http://a_te_hostod:port;
    proxy_set_header Host $host:$server_port;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Host $server_name;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_redirect off;
}
```

A `$` jelű változókat a fordított proxy maga tölti ki.

## Különleges beállítások: régebbi vagy szokatlan szerver

Az alábbiak azoknak szólnak, akik régebbi WordPress-t futtatnak (amit nem érdemes), vagy az SSL-beállításuk szokatlan, például a tanúsítvány másik tartományra szól. Az alapötlet az, hogy a teljes `wp-admin` biztonságos kapcsolaton fusson:

1. Két virtuális hosztot állítasz be ugyanazzal a webhelycímmel: egy biztonságosat és egy nem biztonságosat.
2. A biztonságos hoszton átirányítási szabállyal a nem `wp-admin` forgalmat a nem biztonságos oldalra tereled.
3. A nem biztonságos hoszton átirányítási szabállyal a `wp-admin` felé irányuló forgalmat a biztonságos hosztra tereled.
4. Egy bővítménnyel szűrőt teszel az adminfelület hivatkozásaira, hogy a bekapcsolás után https-re íródjanak át, és a sütik csak titkosított kapcsolaton működjenek.

Ez Apache `mod_rewrite` szabályokkal valósítható meg (az `httpd.conf`-ban vagy `.htaccess` fájlban), de más tárhelykörnyezetre is átültethető.

### Virtuális hosztok

A nem biztonságos webhely mellé kell egy biztonságos szerverre beállított (virtuális) host is. A példában ugyanaz a `DocumentRoot` tartozik mindkettőhöz. Használhatsz más nevű hosztot is (például `wpadmin.sajatoldal.hu`), amelynek a gyökerét a `wpadmin` könyvtárra linkeled. A biztonságos virtuális hosztot kérd a szolgáltatódtól, vagy ha van rendszergazdai hozzáférésed, állítsd be magad. Fontos, hogy a névalapú virtuális hosztolással nem lehet megkülönböztetni több SSL-szervert.

### Átirányítás a nem biztonságos hoszton

A nem biztonságos hoszt `.htaccess` fájljába vagy virtuálishoszt-blokkjába tedd be ezt a szabályt, hogy a `/wp-admin/` és a `wp-login.php` felkeresésekor a böngésző automatikusan a biztonságos hosztra menjen. A WordPress fő átirányítási blokkja elé kell kerülnie:

```apache
RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\ /(.*)\ HTTP/ [NC]
RewriteCond %{HTTPS} !=on [NC]
RewriteRule ^/?(wp-admin/|wp-login\.php) https://example.com%{REQUEST_URI}%{QUERY_STRING} [R=301,QSA,L]
```

Ha használsz szép permalinkeket, ennek a sornak a `RewriteRule ^.*$ - [S=40]` sor elé kell kerülnie. A `THE_REQUEST` használata biztosítja, hogy csak valódi HTTP-kérések íródjanak át, a helyi közvetlen fájlkérések (például include vagy fopen) nem.

### Szabályok a biztonságos hoszton (nem kötelező)

Ezek a szabályok letiltják a nyilvános oldal elérését biztonságos kapcsolaton. Ha a fent említett bővítménnyel a webhely nyilvános részén is bejelentkezve szeretnél maradni, ne add hozzá őket, mert a bővítmény a sütit titkosítatlan kapcsolaton letiltja.

```apache
RewriteRule !^/wp-admin/(.*) - [C]
RewriteRule ^/(.*) https://www.example.com/$1 [QSA,L]
```

Az első szabály a `wp-admin` könyvtárat kiveszi a másodikból, a második pedig a biztonságos oldal forgalmát átküldi a nem biztonságosra, hogy a közönség ne vegyen észre semmit.

### A WordPress webcíme

Egyes bővítmények működéséhez, vagy más okból beállíthatod a WordPress webcímét https-re (például `https://example.com`). A blog címe (a nyilvános webcím) ne változzon.

### Példa konfigurációk

A biztonságos hoszt:

```apache
<VirtualHost nnn.nnn.nnn.nnn:443>
    ServerName www.example.com

    SSLEngine On
    SSLCertificateFile /etc/apache2/ssl/thissite.crt
    SSLCertificateKeyFile /etc/apache2/ssl/thissite.pem
    SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown

    DocumentRoot /var/www/mysite

    <IfModule mod_rewrite.c>
        RewriteEngine On
        RewriteRule !^/wp-(admin|includes)/(.*) - [C]
        RewriteRule ^/(.*) https://www.example.com/$1 [QSA,L]
    </IfModule>

</VirtualHost>
```

A nem biztonságos hoszt:

```apache
<VirtualHost *>
    ServerName www.mysite.com

    DocumentRoot /var/www/ii/mysite

    <Directory /var/www/ii/mysite >
        <IfModule mod_rewrite.c>
            RewriteEngine On
            RewriteBase /
            RewriteCond %{REQUEST_FILENAME} -f [OR]
            RewriteCond %{REQUEST_FILENAME} -d
            RewriteRule ^wp-admin/(.*) https://www.example.com/wp-admin/$1 [C]
            RewriteRule ^.*$ - [S=40]
            RewriteRule ^feed/(feed|rdf|rss|rss2|atom)/?$ /index.php?&feed=$1 [QSA,L]

        </IfModule>
    </Directory>

</VirtualHost>
```

> **Megjegyzés**
>
> Ez a konfiguráció nem teljesen kompatibilis a WordPress 2.8 és újabb változataival, mert azok a `wp-includes` mappából is használnak fájlokat. Az első szabálykészlet átirányítása egyes felhasználóknál biztonsági figyelmeztetést okozhat.

### Átirányítás bejelentkezéshez és regisztrációhoz

Érdemes az SSL-t a bejelentkezéshez és a regisztrációhoz is használni. Ehhez helyettesítő szabályok:

Nem biztonságos hoszton:

```apache
RewriteRule ^/wp-(admin|login|register)(.*) https://www.example.com/wp-$1$2 [C]
```

Biztonságos hoszton:

```apache
RewriteRule !^/wp-(admin|login|register)(.*) - [C]
```

### 443-as vagy 80-as porton futó webhely

```apache
# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /

# 443-as (vagy más, HTTP over SSL) porton futó webhelyhez
RewriteCond %{SERVER_PORT} !^80$
RewriteRule !^wp-(admin|login|register)(.*) - [C]
RewriteRule ^(.*)$ https://%{SERVER_NAME}/$1 [L]

# 80-as porton (http) futó webhelyhez
RewriteCond %{SERVER_PORT}  ^80$
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^wp-(admin|login|register)(.*) https://%{SERVER_NAME}:10001/wp-$1$2 [L]

RewriteCond %{SERVER_PORT}  ^80$
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

</IfModule>
```

### Összefoglalás és korlátok

Ez a módszer nem szünteti meg a WordPress minden eredendő biztonsági kockázatát, és nem véd az úgynevezett köztes támadások (man-in-the-middle) ellen sem. Viszont jóval nehezebbé teszi, hogy egy rosszindulatú személy ellopja a sütijeidet vagy a hitelesítési fejléceidet, és a nevedben belépjen az adminfelületre. Azt is megakadályozza, hogy lehallgassák a tartalmaidat, ami például jogi blogoknál fontos lehet, ahol szigorúan védendő dokumentumvázlatok vannak.

Egy fontos korlát: ha a böngésződben el vannak mentve a sütik vagy jelszavak, és a biztonságos címet (https://…/wp-admin/) elérve a csomagok titkosítatlanul mennek el, a sütik vagy hitelesítési fejlécek elfoghatók. A maximális biztonsághoz ezért mindig kifejezetten a https címet használd, vagy minden új munkamenet elején jelentkezz be újra.