|
Kirjoittaja
|
HTTPS testikäytössä
|
|
Salminen
Niko Salminen
I'm back!
2526 viestiä
Ylläpitäjä
|
#1 kirjoitettu
18.06.2017 13:14
Mikseri.netissä on nyt testikäytössä HTTPS-tuki. Tämä lisää sivuston turvallisuutta sekä nopeutta (HTTP/2 -tuen muodossa).
https://mikseri.net/
Ennen kaiken liikenteen pakottamista HTTPS-salatuksi kaipailen rohkeita vapaaehtoisia testaamaan sivustoa ja raportoimaan tähän ketjuun mahdollisesti ilmenevistä ongelmista. Kaikki tähän mennessä testaamani sivut ovat toimineet, mutta ainakin seuraavia ongelmia voi ilmentyä:
- Jotkut tiedostot kuten kuvat, CSS ja JavaScript saattavat joillain tai kaikilla sivuilla latautua salaamattomasta HTTP-osoitteesta. Selain joko varoittaa sivun turvattomuudesta ja/tai jättää tiedoston tai jopa koko sivun lataamatta.
- Osa linkeistä ja lomakkeista saattaa ohjata selaimen HTTP-osoitteeseen, jolloin suojaus katoaa ja selain saattaa varoittaa asiasta.
Mikäli törmäät ongelmiin, vastaa tähän ketjuun ja anna kuvaus kohtaamastasi ongelmasta, käyttämäsi selain käyttöjärjestelmineen ja versionumeroineen sekä ongelmallisen sivun osoite.
Kiitos ja turvallista selailua!
|
| ^ |
Vastaa
Lainaa
|
|
|
|
BVR
20337 viestiä
|
#2 kirjoitettu
20.06.2017 01:29
Onkostas tää nyt miun laskukoneen hommia, vai Mikserin juttuja? https://www.dropbox.co...
Terveisin, Pöljäeinari84
|
| ^ |
Vastaa
Lainaa
|
|
veezay
bassofriikki
7642 viestiä
Luottokäyttäjä
|
#3 kirjoitettu
20.06.2017 10:58 Muok:20.06.2017 11:11
saan kuvaa (jpg, 727x727, 40kt) lisätessä virheilmoituksen "Kuvan lähettäminen epäonnistui. Yritä uudelleen." mutta sama toistuu kyllä ilman salattua protokollaakin, eli oikeastaan tää ois kannattanut kirjottaa lähinnä tonne palvelinmuutosvirheketjuun.
that being said, oon selannut tän ketjun ilmestyttyä mikseriä pelkästään https:llä ja mitään https-specific ongelmia ei oo esiintynyt.
|
| ^ |
Vastaa
Lainaa
|
|
Salminen
Niko Salminen
I'm back!
2526 viestiä
Ylläpitäjä
|
#4 kirjoitettu
20.06.2017 15:51
veezay kirjoitti:
saan kuvaa (jpg, 727x727, 40kt) lisätessä virheilmoituksen "Kuvan lähettäminen epäonnistui. Yritä uudelleen." mutta sama toistuu kyllä ilman salattua protokollaakin, eli oikeastaan tää ois kannattanut kirjottaa lähinnä tonne palvelinmuutosvirheketjuun.
Korjattu, kuvien lähetykseen oli kovakoodattu polkuja jotka eivät ole uudella palvelimella samoja kuin vanhalla.
BVR:n huomioima outo polku puolestaan on Google Chromen tietoturvaviritys, joka estää sivuja nuskimasta käyttäjän hakemistorakenteita kun kaikki uploadatut tiedostot ilmoittavat olevansa hakemistossa C:\fakepath.
|
| ^ |
Vastaa
Lainaa
|
|
veezay
bassofriikki
7642 viestiä
Luottokäyttäjä
|
#5 kirjoitettu
20.06.2017 19:25
Salminen kirjoitti:
Korjattu, kuvien lähetykseen oli kovakoodattu polkuja jotka eivät ole uudella palvelimella samoja kuin vanhalla.
tattista, nyt olen rumempi kuin koskaan.
|
| ^ |
Vastaa
Lainaa
|
|
morfin_mafer
419 viestiä
|
#6 kirjoitettu
22.06.2017 09:18
Mitä SSL-salauksella on tarkoitus salata? Se ei ole kovin järkevää jos vain sisäänkirjautumisen yhteydessä syötettävät salasanat ja käyttäjätunnus on tarkoitus salata. Mutta jos on tarkoitus salata ihmisten yksityisyyteen liittyvää data niin silloin se on järkevää.
|
| ^ |
Vastaa
Lainaa
|
|
Salminen
Niko Salminen
I'm back!
2526 viestiä
Ylläpitäjä
|
#7 kirjoitettu
22.06.2017 10:56
morfin_mafer kirjoitti:
Mitä SSL-salauksella on tarkoitus salata? Se ei ole kovin järkevää jos vain sisäänkirjautumisen yhteydessä syötettävät salasanat ja käyttäjätunnus on tarkoitus salata. Mutta jos on tarkoitus salata ihmisten yksityisyyteen liittyvää data niin silloin se on järkevää.
Kaikki. Miksei se ole mielestäsi järkevää?
|
| ^ |
Vastaa
Lainaa
|
|
IT
IT Resurrected
13576 viestiä
|
#8 kirjoitettu
22.06.2017 14:47
En ole tämän aihealueen asiantuntuja, mutta eikös tänä päivänä kaikki vähänkään itseään tärkeänä pitävät sivustot ole https:n alla ja takana... YouTube, YLE uutiset, merkittävät verkkokaupat... jne... jne..
Mun puolesta tuo olisi tervetullut uudistus, että koko Mikseri siirtyisi https:n alle joka suhteessa...
|
| ^ |
Vastaa
Lainaa
|
|
|
|
morfin_mafer
419 viestiä
|
#9 kirjoitettu
22.06.2017 14:58
Salminen kirjoitti:
morfin_mafer kirjoitti:
Mitä SSL-salauksella on tarkoitus salata? Se ei ole kovin järkevää jos vain sisäänkirjautumisen yhteydessä syötettävät salasanat ja käyttäjätunnus on tarkoitus salata. Mutta jos on tarkoitus salata ihmisten yksityisyyteen liittyvää data niin silloin se on järkevää.
Kaikki. Miksei se ole mielestäsi järkevää?
SSL-salaus vie palvelimelta resursseja enemmän kuin normaali http.. varsinkin jos palvelimella on Java:lla koodattu backendi esim. Tomcatin ja Apachen takana niin tällöin pitää sekä Tomcat ja Apache SSL-salata erikseen. Ja silloin kannattaa miettiä jos palvelimen CPU ja RAM ovat minimaaliset että kannattaako salata liikennettä pelkkien tunnusten ja salasanojen takia. Tai no ihan miten haluaa. Ei suuri ongelma jos samalla palvelimella on vain yksi sivusto eikä useampia.
|
| ^ |
Vastaa
Lainaa
|
|
Salminen
Niko Salminen
I'm back!
2526 viestiä
Ylläpitäjä
|
#10 kirjoitettu
22.06.2017 15:59
morfin_mafer kirjoitti:
Salminen kirjoitti:
morfin_mafer kirjoitti:
Mitä SSL-salauksella on tarkoitus salata? Se ei ole kovin järkevää jos vain sisäänkirjautumisen yhteydessä syötettävät salasanat ja käyttäjätunnus on tarkoitus salata. Mutta jos on tarkoitus salata ihmisten yksityisyyteen liittyvää data niin silloin se on järkevää.
Kaikki. Miksei se ole mielestäsi järkevää?
SSL-salaus vie palvelimelta resursseja enemmän kuin normaali http.. varsinkin jos palvelimella on Java:lla koodattu backendi esim. Tomcatin ja Apachen takana niin tällöin pitää sekä Tomcat ja Apache SSL-salata erikseen. Ja silloin kannattaa miettiä jos palvelimen CPU ja RAM ovat minimaaliset että kannattaako salata liikennettä pelkkien tunnusten ja salasanojen takia. Tai no ihan miten haluaa. Ei suuri ongelma jos samalla palvelimella on vain yksi sivusto eikä useampia.
Teho ei ole meillä ongelma, apachen ja nginx:n edessä oleva kevyt hitch/varnish -yhdistelmä hoitaa SSL-terminoinnin hyvin pienellä overheadilla. Kirjautumistietojen ohella mm. sessioeväste kulkee jokaisen requestin mukana ja sen kaappaamalla on mahdollista ottaa käyttäjän sessio haltuun. Siksi SSL - tai nykyään oikeammin TLS.
|
| ^ |
Vastaa
Lainaa
|
|
morfin_mafer
419 viestiä
|
#11 kirjoitettu
22.06.2017 17:21
Mulla taas itsellä on 8 Core CPU:lla varustettu 8 Gt RAM:lla varustettu VPS ja siellä ajetaan Tomcatin varassa Apacheen mod_proxyllä integroituna 3 kpl eri ohjelmistoa ja nämä toimivat hiemen hitaasti mutta eivät sentään kaada palvelinta / toisiaan tehon puutteen vuoksi. Sitten on toinen palvelin jossa on 2 Core CPU ja 2 Gt RAMIa ja tämän jälkimmäisen kanssa oli isojakin tehon puuteongelmia ajaa näitä kaikkia J2EE-pohjaisia sovelluksia yhtäaikaa ja ne eivät yhtäaikaa toimineet vaan kaatoivat toinen toisensa.
|
| ^ |
Vastaa
Lainaa
|
|
Salminen
Niko Salminen
I'm back!
2526 viestiä
Ylläpitäjä
|
#12 kirjoitettu
01.07.2017 09:11
morfin_mafer kirjoitti:
Mulla taas itsellä on 8 Core CPU:lla varustettu 8 Gt RAM:lla varustettu VPS ja siellä ajetaan Tomcatin varassa Apacheen mod_proxyllä integroituna 3 kpl eri ohjelmistoa ja nämä toimivat hiemen hitaasti mutta eivät sentään kaada palvelinta / toisiaan tehon puutteen vuoksi. Sitten on toinen palvelin jossa on 2 Core CPU ja 2 Gt RAMIa ja tämän jälkimmäisen kanssa oli isojakin tehon puuteongelmia ajaa näitä kaikkia J2EE-pohjaisia sovelluksia yhtäaikaa ja ne eivät yhtäaikaa toimineet vaan kaatoivat toinen toisensa.
Mikserin palvelimelle on varattu 3 corea ja 6GB RAMia eikä vielä kertaakaan olla käyty tilanteessa jossa kaikki coret olisivat yhtäaikaa käytössä. Kannattaa tutustua kevyisiin reverse proxyihin kuten Varnish ja HAProxy (sekä hitch jos haluaa TLS:n), ne vähentävät mukavasti kuormaa etenkin Tomcatilta, jonka threadit tulevat herkästi täyteen jos useampi hidas clientti latailee yhtäaikaa isoja tiedostoja.
|
| ^ |
Vastaa
Lainaa
|
Ladataan
