Názory k článku
SSL na virtuálních webových serverech se SNI

No, pokud na to prijde, tak SNI je mozne treba u hostingu http://spoje.net/ jenom mi to pripiste do poznamky k objednavce :-)

Google testuje podporu SNI v AppEngine:

http://googleappengine.blogspot.com/2011/10/app-engine-ssl-for-custom-domains-in.html

Jinak koukam, ze mi na linuxaltu nic neuteklo, kdyz sem byl na prednasce o GNU Radiu. Hadam, ze napln prednasky o SNI byla ekvivalentni k naplni tohoto clanku :)

Ano, článek je vlastně přepisem přednášky. To GNU Rádio mě taky zajímalo, takže se těším na záznamy. Prý by letos už opravdu měly být do konce roku venku.

Na mojom iOS 3.2.2 SNI v zabudovanom prehliadaci funguje, cize zmena musela prist niekedy medzi tymito dvoma verziami.

Aha, díky. Já jsem prodával iPhone a před prodejem jsme provedli upgrade myslím z 3.1.2 na 4.2 a začalo to fungovat. Díky za zpřesnění „rozlišení“.

Mám takový dojem, že na windows xp nefunguje více prohlížečů než jen IE. Před rokem jsem SNI zkoušel a v kombinaci xp s Chrome mi SNI nejelo. Pravděpodobně Chrome využívá systémové SSL stejně jako IE.

Od té doby se ale situace mohla změnit.

Chrome to řeší až od verze 6. Předchozí verze používaly systémové SSL knihovny, takže jste se s tím skutečně mohl setkat. Teď už by to zlobit nemělo.

Na jednom stroji muzete mit spoustu SSL serveru i na jedne IP. Staci je pustit na ruznych portech.

A nebo pouzit subjectAltName DNS:jmeno1, DNS: jmeno2, ...

SubjectAltName Extension muze taky nekdy vest k zajimavym vysledkum:

http://paste.ubuntu.com/732547/

(3 certifikaty s mirne "nadprumernym" poctem jmen v SubjectAlterna­tiveName extension)

Možné to samozřejmě je, ale pro běžného uživatele je to nepoužitelné. To už můžete rovnou jet jen na IPv6.

Bezny uzivatel to vubec nepozna, zada do prohlizece www.example.com a tam je presmerovan na https. Meli jsme to tak 2 roky a nikdo si na to reseni nestezoval ani nepotreboval support.

A jak jste si poradili s proxy, které povoluji CONNECT jen na portu 443?

Vubec jsme na ne nenarazili. Zrejme je nikdo nepouziva.

Až na to, že na takovou proxy nenarazí provozovatel webu, ale narazí na ní uživatel a projeví se mu to tak, že se na ten web vůbec nedostane a tedy ani nemá jak dát provozovateli toho webu vědět. A i kdyby měl alternativní cestu a znalosti jak dohledat kontakt na majitele webu, tak kolik lidí se tím kontaktováním bude obtěžovat? IMO naprosto zanedbatelné minimum.

Priste trochu premyslejte - staci se koukat do access logu, kdo pristoupil na stranku, ktera ho ma presmerovat a uz ne na stranku, na kterou mel byt presmerovan. Access log mate preci na serveru k dispozici.

Jo, to mě v ten moment nenapadlo, kdybych po tom cíleně pátral tak bych klienty co na SSL nedorazili našel.

To ale nemění nic na tom, že provozovat HTTPS na nestandardním portu je těžká nouzovka a zoufalost. Osobně bych radši zvolil certifikát s neodpovídajícím hostname.

> Osobně bych radši zvolil certifikát s neodpovídajícím hostname.
Osobne mi to bylo uplne jedno. Zadavatel chtel odstranit problem s varovanim v prohlizeci, kteremu lidi nerozumi bez alokace dalsi IP.

Proxy omezující HTTP a HTTPS komunikaci na porty 80 a 443 používáme ve škole i na internátech.

Jak uz jsem tu psal, nekolik mesicu jsme to sledovali a na nikoho takoveho jsme nenarazili. Ani pote neprisla zadna stiznost (behem 2 let, pak to slo na svuj stroj). Na strasidelne vyhlizejici hlasku z IE si lide obcas stezovali.

absencia stazovatelov neznamena, ze vase riesenie je dobre. Ale pre klud duse si to mozete hovorit

Znate lepsi?

Bezneho uzivatele je nutno naucit, aby zadal https://www.example.com, protoze to presmerovani z http://www.example.com je takova bezpecnostni dira, ze je pak uz skoro zbytecne pouzivat SSL :-)

Polovina beznych uzivatelu zadava adresy do googlu nebo do seznamu. Resit u nich bezpecnost je asi jako chytat mouchy do klece.

Na jedné IP opravdu lze pustit sice webservery a tedy i virtuální hostingy na různých portech, avšak v řadě sítí (firemních, v kavárnách a otevřených wifi sítích nebo některých ISP) se stává, že jsou různé nestandardní porty blokovány, tudíž by se lidé na tyto servery nedostaly vůbec. Je tedy přeci jen z praktického hlediska lepší používat pro HTTP protokol port 80 a pro HTTPS protokol port 443 a přejít k řešení např. pomocí SNI, minimálně do doby, než bude více rozšířené IPv6 (což osobně odhaduji v ČR ještě min. na rok).

www.ElbiaHosting.sk taktiez podporuje

Autor bohužel v článku neřeší menší problém.

Zatímco s pravým SSL případný útočník vidí jen změť dat, která proudí na nějakou IP adresu, s tímhle svinstvem SNI útočník vidí přístup na doménu, třeba porno-zdarma.cz.

A uživatel se to ani nedozví, protože je to "přece přes HTTPS"!

A bez SNI vidi pristup na IPv4 adresu, na ktorej je bez SNI len jedna domena, napriklad porno-zdarma.cz, cize sme si velmi nepomohli.

To je pravda, všechny prohlížeče, které to podporují, posílají v ClientHello automaticky doménu v otevřeném formátu. Jinak se to bohužel vyřešit nedá.

Pokud má uživatel strach z odposlechu, může použít nějaký dodatečný tunel, který zapouzdří spojení jako celek.

Nuž ale s dosť vysokou pravdepodobnosťou takýto útočník uvidí ešte pred https požiadavkom nejakú dns-query, takže až tak veľa sa nedeje.

S "pravym SSL" (bez SNI) stejne utocnik vidi, jaky retezec certifikatu server posila, tudiz utocnik domenu uvidi v Common Name (pripadne Subject Alternative Names).

Dobrý den,

náš hosting FoxyHosting.cz (dříve Space4Web.org) podporuje SNI již velice dlouho. Náročnějším klientům dáme i tu vlastní IP adresu, pokud ji potřebují.

Maly providery ktory pouzivaju ISPconfig 3 maju maly bezvyznamny bodik :)

Nestačí mít weby na různých portech? Třeba na IIS tak lze mít víc webů s SSL.

Snažím se přesvědčit svého poskytovatele hostingu http://www.endora.cz k zavedení SNI. Pokud by měl někdo zájem o hosting za 15 Kč měsíčně s podporou vlastního certifikátu přes SNI ozvěte se na fóru nebo FB.

http://podpora.endora.cz/viewtopic.php?f=6&t=4166
https://www.facebook.com/endora.cz

www.exohosting.sk podporuje SNI

www.vpstech.sk tiez podporuje SNI