https - közvetlen állások

A tegnapi napon, éjszakába nyúló küzdelem eredményeképp az oldal már elérhető a biztonságos módon is:
biztonságos közvetlen állások

Tartalmilag ugyanaz mint a nem-biztonságos.
Igazából azért csináltam az egészet, mert arra számítok, hogy a https idővel emelni fogja az oldalamra vezető linkek pozícióját a google-ben, és így több látogatóm lesz.

A másik szempont, hogy a https gyorsabb mint a http, mert tud párhuzamosan is pl képeket leszedni. Szóval haladni kell a korral.

Amire kevésbé vagyok büszke, az az hogy visszariadtam a Tomcat APR használatától, és a gagyibb jávás megoldás maradt benn. Amit igazából nehezebb is volt konfigurálni, mert a standard certificate és private key helyett egy jávás keystore-ba kell belepakolni a kapott pem fájlokat, és az nem volt egyszerű.

( uid_194 | 2016. 10. 12., sze – 13:10 )

A https nem gyorsabb, mint a http. A sima http is tud parhuzamosan tartalmat betolteni, ez pontosan ugyanugy mukodik mindkettonel.

A http/2, na az mar egy masik teszta lenne, de azt nem tudja a linkelt oldal, ranezesre.

--
|8]

"a https gyorsabb mint a http..."
Ezen en is fennakadtam. Mindegy is, hogy a parhuzamos letoltes vagy mi, de a https gyorsabb soha nem lesz, sot, hiszen ugyanazt a http-t protokollt hasznalja, csak hozzaad egy plusz reteget (titkositas) a kommunikaciohoz.

Ez a parhuzamos letoltes egyebkent "HTTP pipiline" neven fut es nagyon regota resze a HTTP-nek (1.1?).

https://samrueby.com/2015/01/26/why-is-https-faster-than-http/

kb ez lenne az idea, az viszont simán lehet hogy a tomcat 7 ezt alapból nem tudja
egyelőre örültem hogy sikerült az oldal nagyját működésbe hozni https alatt

edit:
igazából ezt láttam meg:
http://www.httpvshttps.com/

( kukukk v | 2016. 10. 12., sze – 13:44 )

Chrome nyafog, hogy vannak dolgok, amik nem https-en keresztul vannak betoltve. Es valoban, vannak dolgok amik http-n keresztul vannak include-olva. Mintha lenne olyan opcio, hogy include eseten elhagyod a "http:" vagy "https:" az url elejerol, es akkor atveszi az oldal meghivasanal hasznalt http vagy https opciot (mar amelyik elerheto mindket modon).

Sic Transit Gloria Mundi

én a chrome/mixed-content alatt két dolgot látok, az egyik az más oldalakról behúzott javascript, illetve font
ezeket tudom orvosolni, gondolom a céloldalak is működnek https alatt

Viszont a találatok előtti kis favicon-okat nem tárolom, és nem én szolgálom ki, hanem csak beágyazom az eredeti urlt az oldalba, azok pedig nem feltétlenül https-en vannak. Megpróbálhatom kicserélni https-re abban reménykedve hogy majd átirányít http-re ha az nincs. Nem tudom ez mennyire jó ötlet.

En azt javasolnam, hogy futtass maga az alkalmazas elott egy kis nginx reverse proxy-t. Azon az nginx-en legyen ket name_virtual host
xx.kozvetlenallasok.hu port 80 - 302 redirect https://xy.kozvetlenallasok.hu -ra.

Aztana masik xy.kozvetlenallasok.hu - port 443
No ebbe a virtserver bepakolod az SSL-t es proxy_pass http://localhost:[tulkeppeni-app-port].

Magyarul az NGINX-ne offloadolod az SSL-t es az alkalmazas csak rajta keresztul erheto el. Ez megnyit egy csomo lehetoseget, hogy cselezgess - statikus tartalom (favikon, css stb) pl mehet egyenesen a webserverbol nem is kell terhelje az alkalmazast magat... Ki tudsz szurni dolgokat stb...

Az eredmeny az lesz hogy ha valaki a 80 portra esik be automatikus atdobodik az SSL-re, egy csomo terhet le tudsz venni az alkalmazasrol - akar belso halora vedetteb helyre is teheted stb...

Ha ezt kerdezni kell, akkor egy rendszergazdara van szukseged. No offense, en elhiszem, hogy jo fejleszto vagy, de ma mar nincsenek reneszansz emberek, nem muszaj ertened az uzemelteteshez is. Fogadj meg egy tanacsot, amig meg ilyen kicsi a projekt, addig tarsulj ossze egy, a fejlesztesi dolgokra is ralato rendszergazdaval, mert kesobb csak kin, fajdalom es szenvedes lesz az eleted.
--
Blog | @hron84
Üzemeltető macik

Sajnos tényleg nem értek a klasszikus webszerver telepítésekhez, még Apache-t se telepítettem soha. De szerintem ezt a konkrét problémát másképp is meg lehet oldani, amíg nem olyan komplex a rendszer hogy kelljen hozzá load balancing meg pénz sincs erre, inkább maradok a sima Tomcat-nél.

Egy nginx felrakasat en is javasolnam, "tisztabb, szarazabb erzes". https es a proxzt is konnyen be tudod allitani, es szerintem meg biztonsagosabb is, ha nem kozvetlen az alkalmazas szervered van kiengedve a webre.

____________________
http://szoftvervasarlas.co.hu - szoftverek legjobb áron

A problema az, hogy a most elkovetett infrastrukturalis tevedesek sokszorosan fogjak megbosszulni magukat, amikor skalazni kell majd a rendszert. Bevallottan nem ertesz az uzemeltetesi reszehez, es ebben az appban benne van az a potencial, hogy egy jo reklammal, egy kicsit improve-olt UX-szal egy sikeres termek legyen. Es nagyon fogod szivni a fogadat, amikor odaersz, megbizol egy rendszergazdat, es eled rak ket surun teleirt A4 oldalt az infrastrukturalis valtoztatasokkal, amiknek ofc kod vonzata is lesz.

Minel elobb rakeszulsz arra, hogy az infrastrukturad jol szervezett, atlathato es konnyen bovitheto legyen, annal tobb penzt sporolsz meg akkor, amikor majd tenylegesen szukseg lesz a bovitesre. Tudom, hogy ezt itthon nem szokas ervkent elfogadni, de ettol meg igy van: a jovoben ervenyesulo elonyok miatt kell most figyelmet forditani ezekre a dolgokra.

De, hogy teljesen oszinte legyek, azt csinalsz, amit akarsz. En csak joindulatuan probaltam javasalatot tenni, de a te projekted, azt kezdesz vele, amit jonak latsz, veletlenul sem akarok beleszolni.
--
Blog | @hron84
Üzemeltető macik

bizonyára igazad van, a konkrét technikai struktúrát illetően, és ha odajutok, lehet hogy pont téged keresnélek meg azzal, hogy skálázhatóvá tedd az infrastruktúrát, de ez az a híd amin akkor kell átmenni amikor már ott vagyok

és jelen pillanatban túl nagy a valószínűsége annak hogy sosem fogok odajutni, ezért nem akarok előre költeni rá
ez a cucc egyelőre egy 512MByte-os vps-en fut, és sokallom a 6ezer forintot amit fizetek rá, nem az a kategória ami elbír akár 1-2 mérnökórát is

6 ezer forint egy 512-es VPS-ert? Az baromi sok! Bakker, en az egy gigas AWS gepemert fizettem ennyit!

Ugyan ez pofatlan onreklam, de nem erdekel: https://www.web2.club/cart.php?gid=8
Oke, nem magyar hostolasu a gep, hanem csehorszagi (legalabbis az a legkozelebbi datacenter), de elvben ennek az oldalnak mindegy, hol fut.
--
Blog | @hron84
Üzemeltető macik

( hrgy84 | 2016. 10. 12., sze – 14:48 )

"A másik szempont, hogy a https gyorsabb mint a http, mert tud párhuzamosan is pl képeket leszedni."

1) a HTTP nem szed le kepeket, a HTTPS sem. Ezek kommunikacios protokollok, amelyeken keresztul kepeket is lehet leszedni.
2) ami a kepeket leszedi, az a bongeszo, amely szamara viszont irrelevans, hogy milyen protokollon keresztul szedi oket parhuzamosan. Az, hogy tud-e parhuzamosan szedni vagy sem, az egyes-egyedul a bongeszo beallitasaitol fugg, semmi egyeb mastol, meg a protokolltol sem.
--
Blog | @hron84
Üzemeltető macik

"Amit igazából nehezebb is volt konfigurálni, mert a standard certificate és private key helyett egy jávás keystore-ba kell belepakolni a kapott pem fájlokat, és az nem volt egyszerű."

Actually, szerintem a Javas keystore ilyen szempontbol jobb, a jelszo altal nem vedett tanusitvanyokat egy jelszoval vedheto store-bol szedi elo. Termeszetesen ez csak akkor jelent biztonsagi tobbletet, ha nem a default "changeme" a keystore jelszava, hanem valami sokkal erosebb. Igen, kicsit nagyobb szopas konfiguralni, de ezt evente/ketevente egyszer kell csak, utana ugyanolyan backupolando fajl mint a pem-ek.