Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Vanaf nu gratis TLS/SSL beschikbaar voor XS4ALL Webhosting
822 views
Skip to first unread message
Daniël Mostertman
Dec 5, 2016, 8:09:01 AM12/5/16
to
Vanaf vandaag hebben we beveiligde verbindingen mogelijk gemaakt voor al
onze Webhosting-klanten! Klanten hoeven hier zelf niets voor in te stellen:
Het staat standaard voor al onze klanten aan.
Bezoekers van deze websites kunnen er direct gebruik van maken door in de
adresbalk https:// voor de websitenaam te plaatsen (website-eigenaren kunnen
dit forceren, zie hiervoor onderaan dit bericht).
De websites zullen hetzelfde blijven functioneren over de onbeveiligde
verbinding. Om de websites foutloos over de beveiligde verbinding te laten
werken, is het belangrijk dat er op de website niet verwezen wordt naar
onbeveiligde bronnen. Het is daarom van belang dat bronnen op de website die
nog naar onveilige bronnen wijzen (http://), gewijzigd moeten naar de
nieuwe, veilige variant (https://).
Technische punten voor de liefhebbers:
- Één certificaat per hostname (privacy).
- Certificaten zijn 90 dagen geldig, renew vindt automatisch plaats.
- Private keys zijn 4096 bits (RSA).
- SHA-256 (RSA) signatures.
- OCSP-stapling staat aan.
- Forward secrecy.
- HTTP/2 wordt ondersteund (ALPN & NPN).
- SPDY/3.1 wordt niet ondersteund.
Er vallen nog extra features aan te zetten door de beheerder van de
website(s) via een .htaccess bestand in de root van de website. Goede
voorbeelden hierbij zijn "redirect altijd naar https://", of de zogenaamde
Strict-Transport-Security header (HSTS) zodat browsers altijd https://
blijven proberen (zelfs wanneer de gebruiker http:// intikt). Gebruik die
laatste zorgvuldig, want het wordt gecached in alle browsers van alle
bezoekers en valt niet heel simpel ongedaan te maken.
#---------------------------------------------------------------------------
# Voorbeelden voor in htdocs/.htaccess :
#---------------------------------------------------------------------------
# Geforceerde http:// => https:// redirect.
<IfModule mod_rewrite.c>
RewriteCond %{HTTP:X-Forwarded-Scheme} =http
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=307]
</IfModule>
# Strict-Transport-Security header (hier gecached voor 4 uur)
<IfModule mod_headers.c>
Header set Strict-Transport-Security "max-age=14400" env=HTTPS
</IfModule>
#---------------------------------------------------------------------------
Mochten er nog andere vragen zijn, dan hoor ik ze graag.
--
Daniël Mostertman
XS4ALL Systeembeheer
onze Webhosting-klanten! Klanten hoeven hier zelf niets voor in te stellen:
Het staat standaard voor al onze klanten aan.
Bezoekers van deze websites kunnen er direct gebruik van maken door in de
adresbalk https:// voor de websitenaam te plaatsen (website-eigenaren kunnen
dit forceren, zie hiervoor onderaan dit bericht).
De websites zullen hetzelfde blijven functioneren over de onbeveiligde
verbinding. Om de websites foutloos over de beveiligde verbinding te laten
werken, is het belangrijk dat er op de website niet verwezen wordt naar
onbeveiligde bronnen. Het is daarom van belang dat bronnen op de website die
nog naar onveilige bronnen wijzen (http://), gewijzigd moeten naar de
nieuwe, veilige variant (https://).
Technische punten voor de liefhebbers:
- Één certificaat per hostname (privacy).
- Certificaten zijn 90 dagen geldig, renew vindt automatisch plaats.
- Private keys zijn 4096 bits (RSA).
- SHA-256 (RSA) signatures.
- OCSP-stapling staat aan.
- Forward secrecy.
- HTTP/2 wordt ondersteund (ALPN & NPN).
- SPDY/3.1 wordt niet ondersteund.
Er vallen nog extra features aan te zetten door de beheerder van de
website(s) via een .htaccess bestand in de root van de website. Goede
voorbeelden hierbij zijn "redirect altijd naar https://", of de zogenaamde
Strict-Transport-Security header (HSTS) zodat browsers altijd https://
blijven proberen (zelfs wanneer de gebruiker http:// intikt). Gebruik die
laatste zorgvuldig, want het wordt gecached in alle browsers van alle
bezoekers en valt niet heel simpel ongedaan te maken.
#---------------------------------------------------------------------------
# Voorbeelden voor in htdocs/.htaccess :
#---------------------------------------------------------------------------
# Geforceerde http:// => https:// redirect.
<IfModule mod_rewrite.c>
RewriteCond %{HTTP:X-Forwarded-Scheme} =http
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=307]
</IfModule>
# Strict-Transport-Security header (hier gecached voor 4 uur)
<IfModule mod_headers.c>
Header set Strict-Transport-Security "max-age=14400" env=HTTPS
</IfModule>
#---------------------------------------------------------------------------
Mochten er nog andere vragen zijn, dan hoor ik ze graag.
--
Daniël Mostertman
XS4ALL Systeembeheer
A. Dumas
Dec 5, 2016, 12:09:11 PM12/5/16
to
On 05/12/2016 14:08, Daniël Mostertman wrote:
> Vanaf vandaag hebben we beveiligde verbindingen mogelijk gemaakt voor al
> onze Webhosting-klanten! Klanten hoeven hier zelf niets voor in te stellen:
> Het staat standaard voor al onze klanten aan.
Mooi. Het werkt trouwens ook (al een tijdje) voor homepages
> Vanaf vandaag hebben we beveiligde verbindingen mogelijk gemaakt voor al
> onze Webhosting-klanten! Klanten hoeven hier zelf niets voor in te stellen:
> Het staat standaard voor al onze klanten aan.
*.home.xs4all.nl.
Daniël Mostertman
Dec 5, 2016, 12:29:48 PM12/5/16
to
On 2016-12-05 18:09, A. Dumas wrote:
> Mooi. Het werkt trouwens ook (al een tijdje) voor homepages *.home.xs4all.nl.
Klopt, die hebben het al bijna een jaar (januari).
> Mooi. Het werkt trouwens ook (al een tijdje) voor homepages *.home.xs4all.nl.
Daniel Dent
Dec 8, 2016, 2:49:00 AM12/8/16
to
Op 5-12-2016 om 14:08 schreef Daniël Mostertman:
Ik was mij al een tijdje aan het inlezen en beraden over deze materie,
en hoe ermee om te gaan, nu organisaties als Google, Apple en Mozilla er
volgend jaar echt over gaan zeuren als je geen SSL-certificaat ingesteld
hebt.
En nu wordt het zonder enige inspanning opgelost door XS4ALL! Daar word
ik heel erg vrolijk van... :-D
Ik beheer namelijk ook nog wat hobby-websites bij andere (goedkope)
webhosts, en die lijken in SSL een nieuw verdienmodel te zien, ondermeer
door stevige prijzen te vragen voor dedicated IP-adressen, omdat ze geen
Server Name Indication (SNI) (willen) ondersteunen.
Overigens vind ik dat veel van de nobele doelstellingen van het
SSL-circus in de praktijk onderuit gehaald worden. Zo kun je eigenlijk
niet fatsoenlijk webbrowsen zonder alle certificaatwaarschuwingen die
een browser kan tonen, uit te schakelen. Want vrijwel elke https-website
genereert wel één of meerdere waarschuwingen over verlopen of onjuiste
certificaten, of over gemengde inhoud. En als iedereen die
waarschuwingen uitschakelt, of negeert, hoeveel waarde heeft die
certificering dan nog?
> Vanaf vandaag hebben we beveiligde verbindingen mogelijk gemaakt voor al
> onze Webhosting-klanten! Klanten hoeven hier zelf niets voor in te stellen:
> Het staat standaard voor al onze klanten aan.
>
Geweldig!
> onze Webhosting-klanten! Klanten hoeven hier zelf niets voor in te stellen:
> Het staat standaard voor al onze klanten aan.
>
Ik was mij al een tijdje aan het inlezen en beraden over deze materie,
en hoe ermee om te gaan, nu organisaties als Google, Apple en Mozilla er
volgend jaar echt over gaan zeuren als je geen SSL-certificaat ingesteld
hebt.
En nu wordt het zonder enige inspanning opgelost door XS4ALL! Daar word
ik heel erg vrolijk van... :-D
Ik beheer namelijk ook nog wat hobby-websites bij andere (goedkope)
webhosts, en die lijken in SSL een nieuw verdienmodel te zien, ondermeer
door stevige prijzen te vragen voor dedicated IP-adressen, omdat ze geen
Server Name Indication (SNI) (willen) ondersteunen.
Overigens vind ik dat veel van de nobele doelstellingen van het
SSL-circus in de praktijk onderuit gehaald worden. Zo kun je eigenlijk
niet fatsoenlijk webbrowsen zonder alle certificaatwaarschuwingen die
een browser kan tonen, uit te schakelen. Want vrijwel elke https-website
genereert wel één of meerdere waarschuwingen over verlopen of onjuiste
certificaten, of over gemengde inhoud. En als iedereen die
waarschuwingen uitschakelt, of negeert, hoeveel waarde heeft die
certificering dan nog?
Rob
Dec 8, 2016, 4:15:10 AM12/8/16
to
Daniel Dent <daa...@xs4all.nl> wrote:
> Overigens vind ik dat veel van de nobele doelstellingen van het
> SSL-circus in de praktijk onderuit gehaald worden.
En dan met name door dit soort initiatieven!
> Overigens vind ik dat veel van de nobele doelstellingen van het
> SSL-circus in de praktijk onderuit gehaald worden.
Want waarvoor waren die certificaten met name bedoeld?
Om te bepalen met WIE je communiceert, zodat je kunt controleren of
dat wel de persoon is die je vertrouwt.
En wat gebeurt er nu meer en meer? Certificaten worden kado gegeven
zonder enige validatie, puur alleen op basis van de registratie van
een domeinnaam.
Om nu nog validatie te kunnen doen moet je zowat wel een superduur
EV certificaat aanvragen, de rest is down the drain wat betrouwbaarheid
betreft.
richard lucassen
Dec 8, 2016, 5:08:11 AM12/8/16
to
On 08 Dec 2016 09:15:09 GMT
Plus dat webservers nu een hele bergen extra ssl/tls code krijgen
waardoor de kans op vulnerabilities groter wordt. Terwijl het vaak niet
nodig is omdat in heel veel gevallen de inhoud expliciet openbaar is.
"Security theatre" heet het.
--
richard lucassen
http://contact.xaq.nl/
waardoor de kans op vulnerabilities groter wordt. Terwijl het vaak niet
nodig is omdat in heel veel gevallen de inhoud expliciet openbaar is.
"Security theatre" heet het.
--
richard lucassen
http://contact.xaq.nl/
Daniël Mostertman
Dec 8, 2016, 6:00:34 AM12/8/16
to
On 2016-12-08 10:15, Rob wrote:
> En dan met name door dit soort initiatieven!
> Want waarvoor waren die certificaten met name bedoeld?
> Om te bepalen met WIE je communiceert, zodat je kunt controleren of
> dat wel de persoon is die je vertrouwt.
> En wat gebeurt er nu meer en meer? Certificaten worden kado gegeven
> zonder enige validatie, puur alleen op basis van de registratie van
> een domeinnaam.
> Om nu nog validatie te kunnen doen moet je zowat wel een superduur
> EV certificaat aanvragen, de rest is down the drain wat betrouwbaarheid
> betreft.
>
Ik wil hier toch nog even op reageren, want delen hiervan zijn simpelweg
> En dan met name door dit soort initiatieven!
> Want waarvoor waren die certificaten met name bedoeld?
> Om te bepalen met WIE je communiceert, zodat je kunt controleren of
> dat wel de persoon is die je vertrouwt.
> En wat gebeurt er nu meer en meer? Certificaten worden kado gegeven
> zonder enige validatie, puur alleen op basis van de registratie van
> een domeinnaam.
> Om nu nog validatie te kunnen doen moet je zowat wel een superduur
> EV certificaat aanvragen, de rest is down the drain wat betrouwbaarheid
> betreft.
>
niet waar.
Naar mijn mening vindt er een betere validatie plaats bij deze
certifcaten dan bij menig andere partij, en directer. Hiermee wordt
geverifiëerd dat de aanvrager inderdaad controle heeft over de hostname
waarvoor deze aangevraagd wordt. In tegenstelling van andere CA's
waarbij lukraak willekeurige e-mail adressen ter verificatie worden
gebruikt binnen het domein. Hiermee is het in het verleden al
voorgekomen dat een CA met een zelfverzonnen e-mail adres, een
certificaat voor xs4all.nl heeft gevalideerd.
De aantallen e-mail adressen die de andere CA's hiervoor hanteren loopt
extreem en oncontroleerbaar uit de hand. De CA die wij gebruiken, maakt
geen vrijwel geen onderscheid op basis van domeinnaam, maar op hostname
die in het certificaat komt. Elke hostname wordt los geverifiëerd
a.d.h.v. een token + callback systeem om niet alleen te controleren dat
de hostname het verzoek accepteert, maar ook de gegenereerde token
overeenkomt en nog geldig is.
Extended Validation is inderdaad wél een uitbreiding hierop, maar
hiervoor moet je verplicht een KvK-inschrijving hebben én bereikbaar
zijn op dat contactnummer, en een hele andere molen doorgaan. Dit is
voor vrijwel niemand haalbaar. Daarnaast is het, omdat er zoveel
controle bij komt kijken, niet te betalen voor persoonlijke sites.
Moeten al die andere websites dan maar zonder beveiligde verbinding
gebruikt worden? Certificaten zijn één ding, encryptie is wat anders.
Wij bieden niet alleen certificaten van een geaccepteerde CA, maar wat
we vooral bieden en de strekking van de aankondiging ook was: Beveiligde
verbindingen. We bieden al een tijdje DNSSEC aan op onze resolvers. We
zijn aan het kijken om DNSSEC ook aan te kunnen krijgen voor domeinen
die bij ons gehost worden, maar dat gaat helaas nog even duren. Zodra
dat live staat, kun je wel degelijk zeker weten dat je op de echte site
uitkomt. Verifiëren of een certificaat wel geldig is, wordt daarmee ook
overbodig.
Wat niet overbodig is of wordt, is de mate van beveiliging door
ondersteunde ciphers en protocollen. Wij ondersteunen een moderne set
van ciphers en protocollen, waarmee de verbinding vanaf de browser tot
onze servers beveiligd wordt. Meelezen wordt daarmee vrijwel onmogelijk.
Als ik een tientje kreeg voor elke klant die op vakantie z'n WordPress
bij zit te werken over een onveilige verbinding, waarna de logingegevens
misbruikt worden, kon ik toch nog wel een aardig iets aanschaffen.
Naar mijn mening is dan waar certificaten door verstrekt worden dan ook
niet het belangrijkste punt van "https", maar de beveiligde verbinding.
Identiteitsverificatie kan beter plaatsvinden door technieken als
DNSSEC. Ik ben het met jullie eens dat certificaten hier niet voor
geschikt zijn. Zeker in dit tijdperk niet. Maar TLS en bijbehorende
ciphers staan daar, nogmaals, los van.
Daniël Mostertman
Dec 8, 2016, 6:03:08 AM12/8/16
to
On 2016-12-08 11:08, richard lucassen wrote:
> Plus dat webservers nu een hele bergen extra ssl/tls code krijgen
> waardoor de kans op vulnerabilities groter wordt. Terwijl het vaak niet
> nodig is omdat in heel veel gevallen de inhoud expliciet openbaar is.
>
> "Security theatre" heet het.
Vulnerabilities en schijnveiligheid daargelaten, TLS-beveiligde
> Plus dat webservers nu een hele bergen extra ssl/tls code krijgen
> waardoor de kans op vulnerabilities groter wordt. Terwijl het vaak niet
> nodig is omdat in heel veel gevallen de inhoud expliciet openbaar is.
>
> "Security theatre" heet het.
verbindingen zijn nog altijd veiliger dan je logingegevens of
contactformulieren versturen over een totaal onbeveiligde en meeleesbare
verbinding. Meeste verkeer naar de klantwebsites komt namelijk zeker
niet van binnen ons eigen netwerk.
Wij forceren ook het gebruik van TLS niet. Bezoekers van websites van
klanten kunnen zelf kiezen of ze het wel of niet gebruiken, maar vanaf
2018 zijn Chrome en Mozilla van plan waarschuwingspagina's te laten zien
voor onbeveiligde websites zoals ze nu ook doen voor sites met invalid
certificates.
Encryptie is nog altijd beter dan geen encryptie, mijns inziens.
Philip Homburg
Dec 8, 2016, 6:53:01 AM12/8/16
to
In article <slrno4i94t...@xs9.xs4all.nl>,
heb ik wel een idee waar ze gevestigd zijn, maar van de meeste niet.
Dus een DV cert is in de meeste gevallen prima.
Stel iemand registreert een manege met de naam Amazone. Zou het iemand opvallen
als een EV cert for Amazone, NL niet Amazon is?
--
We just programmed the computers to revive us when it was all over... they
were index linked to the [...] stock market prices you see, so that we'd
be revived when everybody else had rebuilt the economy enough to be able to
afford our rather expensive services again. -- Slartibartfast in THHGTTG
Rob <nom...@example.com> wrote:
>En dan met name door dit soort initiatieven!
>Want waarvoor waren die certificaten met name bedoeld?
>Om te bepalen met WIE je communiceert, zodat je kunt controleren of
>dat wel de persoon is die je vertrouwt.
>En wat gebeurt er nu meer en meer? Certificaten worden kado gegeven
>zonder enige validatie, puur alleen op basis van de registratie van
>een domeinnaam.
Met wie ik communiceer is meestal een website. Van een paar bedrijven
>En dan met name door dit soort initiatieven!
>Want waarvoor waren die certificaten met name bedoeld?
>Om te bepalen met WIE je communiceert, zodat je kunt controleren of
>dat wel de persoon is die je vertrouwt.
>En wat gebeurt er nu meer en meer? Certificaten worden kado gegeven
>zonder enige validatie, puur alleen op basis van de registratie van
>een domeinnaam.
heb ik wel een idee waar ze gevestigd zijn, maar van de meeste niet.
Dus een DV cert is in de meeste gevallen prima.
Stel iemand registreert een manege met de naam Amazone. Zou het iemand opvallen
als een EV cert for Amazone, NL niet Amazon is?
--
We just programmed the computers to revive us when it was all over... they
were index linked to the [...] stock market prices you see, so that we'd
be revived when everybody else had rebuilt the economy enough to be able to
afford our rather expensive services again. -- Slartibartfast in THHGTTG
Daniël Mostertman
Dec 8, 2016, 8:01:47 AM12/8/16
to
On 2016-12-08 12:32, Philip Homburg wrote:
> Met wie ik communiceer is meestal een website. Van een paar bedrijven
> heb ik wel een idee waar ze gevestigd zijn, maar van de meeste niet.
>
> Dus een DV cert is in de meeste gevallen prima.
Precies; en in het geval van Let's Encrypt wordt het zelfs op host-basis
> Met wie ik communiceer is meestal een website. Van een paar bedrijven
> heb ik wel een idee waar ze gevestigd zijn, maar van de meeste niet.
>
> Dus een DV cert is in de meeste gevallen prima.
geverifiëerd, dus ook "subdomein", ipv "domein".
(Wij maken gebruik van Let's Encrypt.)
> Stel iemand registreert een manege met de naam Amazone. Zou het iemand
opvallen
> als een EV cert for Amazone, NL niet Amazon is?
Identiteitsvalidatie van de eigenaar van de website van waar je naar toe
gaat staat los van de veiligheid van de verbinding van hoe je op die
website uitkomt.
DNSSEC is een veel betere validatie-optie t.o.v. SSL CA's.
DV en EV maken daarin ook niet uit. Als je genoeg geld neerlegt is er
van alles mogelijk. Zo bleek ook bij o.a. StartCom/WoSign van wie sinds
21 oktober j.l. geen nieuwe certificaten meer toegelaten worden door
Chrome en Mozilla.
Philip Homburg
Dec 8, 2016, 8:53:00 AM12/8/16
to
In article <584959b9$0$21522$e4fe...@news.xs4all.nl>,
vergeten wat voor bizarre reden ze verzonnen hebben om geen DANE validation
te doen.
Er is gelukkig wel een goede plug-in: https://www.dnssec-validator.cz/
=?UTF-8?Q?Dani=c3=abl_Mostertman?= <dan...@xs4all.nederland.invalid> wrote:
>DNSSEC is een veel betere validatie-optie t.o.v. SSL CA's.
>DV en EV maken daarin ook niet uit.
Het zou leuk zijn als browsers daar ook wat mee gaan doen. Ik ben even
>DNSSEC is een veel betere validatie-optie t.o.v. SSL CA's.
>DV en EV maken daarin ook niet uit.
vergeten wat voor bizarre reden ze verzonnen hebben om geen DANE validation
te doen.
Er is gelukkig wel een goede plug-in: https://www.dnssec-validator.cz/
Rob
Dec 8, 2016, 9:01:09 AM12/8/16
to
Daniël Mostertman <dan...@xs4all.nederland.invalid> wrote:
> Ik wil hier toch nog even op reageren, want delen hiervan zijn simpelweg
> niet waar.
>
> Ik wil hier toch nog even op reageren, want delen hiervan zijn simpelweg
> niet waar.
>
> Extended Validation is inderdaad wél een uitbreiding hierop, maar
> hiervoor moet je verplicht een KvK-inschrijving hebben én bereikbaar
> zijn op dat contactnummer, en een hele andere molen doorgaan. Dit is
> voor vrijwel niemand haalbaar. Daarnaast is het, omdat er zoveel
> controle bij komt kijken, niet te betalen voor persoonlijke sites.
>
> Moeten al die andere websites dan maar zonder beveiligde verbinding
> gebruikt worden? Certificaten zijn één ding, encryptie is wat anders.
Waar het wringt is dat encryptie zonder identiteitsvalidatie minder
> hiervoor moet je verplicht een KvK-inschrijving hebben én bereikbaar
> zijn op dat contactnummer, en een hele andere molen doorgaan. Dit is
> voor vrijwel niemand haalbaar. Daarnaast is het, omdat er zoveel
> controle bij komt kijken, niet te betalen voor persoonlijke sites.
>
> Moeten al die andere websites dan maar zonder beveiligde verbinding
> gebruikt worden? Certificaten zijn één ding, encryptie is wat anders.
effectief is, omdat een man-in-the-middle zich kan voordoen als de
partij waarmee je denkt te connecten, en dan dus toch weer de plain
tekst kan zien.
Het hele systeem van certificaten uitgegeven door "vertrouwde partijen"
is wat dat betreft al zwakjes, het was beter geweest als er ook een
register was voor welk certificaat door wie in gebruik is. Bijvoorbeeld
via DNS icm DNSSEC inderdaad. Het is nu al voldoende als er 1 certificaat
uitgever te overtuigen is, of dat nou Verisign of Turk of Taiwan telecom
is maakt niks uit. Dat rammelt.
Door ook nog automatische uitgevers zoals Let's encrypt te gaan
toevoegen kan iedereen die toegang heeft tot het beheer van een site
daar een certificaat voor aanvragen, dus ook een hacker (of laten we
zeggen cracker). Dat verzwakt het hele system nog verder. Maar het
was al kapot, dus let's do it. Denkt men daar kennelijk.
richard lucassen
Dec 8, 2016, 9:16:35 AM12/8/16
to
On Thu, 8 Dec 2016 12:03:07 +0100
Daniël Mostertman <dan...@xs4all.nederland.invalid> wrote:
> > Plus dat webservers nu een hele bergen extra ssl/tls code krijgen
> > waardoor de kans op vulnerabilities groter wordt. Terwijl het vaak
> > niet nodig is omdat in heel veel gevallen de inhoud expliciet
> > openbaar is.
> >
> > "Security theatre" heet het.
>
> Vulnerabilities en schijnveiligheid daargelaten, TLS-beveiligde
> verbindingen zijn nog altijd veiliger dan je logingegevens of
> contactformulieren versturen over een totaal onbeveiligde en
> meeleesbare verbinding. Meeste verkeer naar de klantwebsites komt
> namelijk zeker niet van binnen ons eigen netwerk.
Mee eens, maar je hebt het dan wel over sites die 25 jaar geleden al
Daniël Mostertman <dan...@xs4all.nederland.invalid> wrote:
> > Plus dat webservers nu een hele bergen extra ssl/tls code krijgen
> > waardoor de kans op vulnerabilities groter wordt. Terwijl het vaak
> > niet nodig is omdat in heel veel gevallen de inhoud expliciet
> > openbaar is.
> >
> > "Security theatre" heet het.
>
> Vulnerabilities en schijnveiligheid daargelaten, TLS-beveiligde
> verbindingen zijn nog altijd veiliger dan je logingegevens of
> contactformulieren versturen over een totaal onbeveiligde en
> meeleesbare verbinding. Meeste verkeer naar de klantwebsites komt
> namelijk zeker niet van binnen ons eigen netwerk.
https behoorden te zijn. Als je logingegevens unencrypt over het netwerk
stuurt dan hoor je als beheerder met je tengels van een webserver af te
blijven. Evenals in het geval dat de inhoud niet door meelezers
bekeken mag worden.
Maar sites die alleen maar inhoud aanbieden die toch openbaar is en
waarvan men nou juist wil dat het overal opgeslagen wordt, daar is het
een onnodige maatregel voor.
> Wij forceren ook het gebruik van TLS niet. Bezoekers van websites van
> klanten kunnen zelf kiezen of ze het wel of niet gebruiken, maar vanaf
> 2018 zijn Chrome en Mozilla van plan waarschuwingspagina's te laten
> zien voor onbeveiligde websites zoals ze nu ook doen voor sites met
> invalid certificates.
op "yes" klikken en verder. Is er dan echt iets aan de hand dan ben je
de sigaar. Net als de cookiewet schiet het zijn doel ver voorbij.
> Encryptie is nog altijd beter dan geen encryptie, mijns inziens.
Maak dan de URL balk geel o.i.d. maar ga geen waarschuwingen geven waar
je "yes" op moet klikken. Binnen een dag verschijnen er dan wel plugins
die dat voor je gaan doen. Net zoals voor cookies.
R.
Paul Slootman
Dec 8, 2016, 12:26:39 PM12/8/16
to
Daniel Dent <daa...@xs4all.nl> wrote:
>
>een browser kan tonen, uit te schakelen. Want vrijwel elke https-website
>genereert wel één of meerdere waarschuwingen over verlopen of onjuiste
>certificaten, of over gemengde inhoud. En als iedereen die
Als ik een site tegenkom waar ik mijn gegevens in moet kloppen en
>
>een browser kan tonen, uit te schakelen. Want vrijwel elke https-website
>genereert wel één of meerdere waarschuwingen over verlopen of onjuiste
>certificaten, of over gemengde inhoud. En als iedereen die
dergelijke meldingen geeft, dan ga ik echt niet verder en zal er
minimaal een mailtje aan wagen. Toch komt dat nagenoeg nooit voor; wel
op random andere sites waar ik gewoon via google opgekomen ben omdat ik
wat wil weten. Dan interesseert het mij niet. Maar ook dat komt niet
echt vaak voor. Misschien ligt het aan de soort site die ik bezoek ;-)
Paul
Richard Bos
Dec 15, 2016, 4:00:39 PM12/15/16
to
=?UTF-8?Q?Dani=c3=abl_Mostertman?= <dan...@xs4all.nederland.invalid>
wrote:
> Encryptie is nog altijd beter dan geen encryptie, mijns inziens.
Een slot is nog altijd beter dan geen slot.
Ook op het hek rond een voetbalveld? De deur naar de gangkast?
Richard
wrote:
> Encryptie is nog altijd beter dan geen encryptie, mijns inziens.
Ook op het hek rond een voetbalveld? De deur naar de gangkast?
Richard
Jaap Keuter
Jan 5, 2017, 2:51:55 PM1/5/17
to
On 2016-12-05 13:08:59 +0000, Dani l Mostertman said:
> Vanaf vandaag hebben we beveiligde verbindingen mogelijk gemaakt voor al
> onze Webhosting-klanten! Klanten hoeven hier zelf niets voor in te stellen:
> Het staat standaard voor al onze klanten aan.
>
>
>
> Vanaf vandaag hebben we beveiligde verbindingen mogelijk gemaakt voor al
> onze Webhosting-klanten! Klanten hoeven hier zelf niets voor in te stellen:
> Het staat standaard voor al onze klanten aan.
>
>
>
> Mochten er nog andere vragen zijn, dan hoor ik ze graag.
Het zou mooi zijn al ik dit ook op mijn bij mijn glasvezel abonnement
horende subdomain van xs4all.nl zou kunnen doen. Eigen servertje
draaien, via mijn Fritzbox aan mijn glasvezel, 100Mb met de
buitenwereld is genoeg. Maar als ik een Let's Encrypt certificate
aanvraag krijg ik terug dat er al te veel voor het xs4all.nl domain
zijn uitgegeven. ""There were too many requests of a given type ::
Error creating new cert :: Too many certificates already issued for:
xs4all.nl"
Nader onderzoek (bijvoorbeeld
https://community.letsencrypt.org/t/too-many-certificates-already-issued-for-myfritz-net/10416)
vertelt me dat dit probleem al kan worden opgelost, als XS4ALL haar
domein wil toevoegen aan de Public Suffix List
(https://publicsuffix.org).
Deze vraag bij de helpdesk geponeerd, helaas geen bemoedigend antwoord
gekregen. "Helaas zijn er nog geen plannen bij de productmanager om dit
op de gratis XS4ALL domeinen te activeren. Ik zal uw wens bij deze
doorgeven."
Voorllopig maar een self signed certificate ingevoerd...
Paul Slootman
Jan 6, 2017, 5:58:41 AM1/6/17
to
Jaap Keuter <em...@domain.com> wrote:
>Het zou mooi zijn al ik dit ook op mijn bij mijn glasvezel abonnement
>horende subdomain van xs4all.nl zou kunnen doen. Eigen servertje
>draaien, via mijn Fritzbox aan mijn glasvezel, 100Mb met de
>buitenwereld is genoeg. Maar als ik een Let's Encrypt certificate
>aanvraag krijg ik terug dat er al te veel voor het xs4all.nl domain
>zijn uitgegeven. ""There were too many requests of a given type ::
>Error creating new cert :: Too many certificates already issued for:
>xs4all.nl"
Gewoon voor 7,45 (4,95 1e jaar) bij webstekker.nl een eigen domein
>Het zou mooi zijn al ik dit ook op mijn bij mijn glasvezel abonnement
>horende subdomain van xs4all.nl zou kunnen doen. Eigen servertje
>draaien, via mijn Fritzbox aan mijn glasvezel, 100Mb met de
>buitenwereld is genoeg. Maar als ik een Let's Encrypt certificate
>aanvraag krijg ik terug dat er al te veel voor het xs4all.nl domain
>zijn uitgegeven. ""There were too many requests of a given type ::
>Error creating new cert :: Too many certificates already issued for:
>xs4all.nl"
registreren, en dan bij xs4all www.jouweigendomein koppelen aan je
glasvezel IP adres, en dan bij letsencrypt een gratis cert regelen.
Dan zit je ook niet vast aan xs4all mocht je ooit je site ergens anders
willen onderbrengen.
Paul
A. Dumas
Jan 6, 2017, 6:51:41 AM1/6/17
to
On 06/01/2017 11:58, Paul Slootman wrote:
> Gewoon voor 7,45 (4,95 1e jaar) bij webstekker.nl een eigen domein
> registreren, en dan bij xs4all www.jouweigendomein koppelen aan je
> glasvezel IP adres, en dan bij letsencrypt een gratis cert regelen.
> Dan zit je ook niet vast aan xs4all mocht je ooit je site ergens anders
> willen onderbrengen.
Ja, of natuurlijk elke andere hoster waar je je DNS-records kunt
> Gewoon voor 7,45 (4,95 1e jaar) bij webstekker.nl een eigen domein
> registreren, en dan bij xs4all www.jouweigendomein koppelen aan je
> glasvezel IP adres, en dan bij letsencrypt een gratis cert regelen.
> Dan zit je ook niet vast aan xs4all mocht je ooit je site ergens anders
> willen onderbrengen.
bewerken. Want naam->ip moet geloof ik eerst goed staan voordat je bij
Xs4all de reverse kunt instellen.
Philip Homburg
Jan 6, 2017, 4:53:04 PM1/6/17
to
In article <586f84c9$0$21537$e4fe...@news.xs4all.nl>,
Geen probleem als je graag een andere naam in reverse DNS wil hebben, maar
het staat los van het eigenlijke probleem.
A. Dumas <alex...@dumas.fr.invalid> wrote:
>Ja, of natuurlijk elke andere hoster waar je je DNS-records kunt
>bewerken. Want naam->ip moet geloof ik eerst goed staan voordat je bij
>Xs4all de reverse kunt instellen.
Waarom zou je voor een website reverse DNS veranderen?
>Ja, of natuurlijk elke andere hoster waar je je DNS-records kunt
>bewerken. Want naam->ip moet geloof ik eerst goed staan voordat je bij
>Xs4all de reverse kunt instellen.
Geen probleem als je graag een andere naam in reverse DNS wil hebben, maar
het staat los van het eigenlijke probleem.
A. Dumas
Jan 7, 2017, 2:04:05 AM1/7/17
to
On 06/01/2017 22:29, Philip Homburg wrote:
> In article <586f84c9$0$21537$e4fe...@news.xs4all.nl>,
> A. Dumas <alex...@dumas.fr.invalid> wrote:
>> Ja, of natuurlijk elke andere hoster waar je je DNS-records kunt
>> bewerken. Want naam->ip moet geloof ik eerst goed staan voordat je bij
>> Xs4all de reverse kunt instellen.
>
> Waarom zou je voor een website reverse DNS veranderen?
>
> Geen probleem als je graag een andere naam in reverse DNS wil hebben, maar
> het staat los van het eigenlijke probleem.
Huh? Niet een andere, dezelfde. Jouwdomein->jouwDSLadres bij de hoster,
> In article <586f84c9$0$21537$e4fe...@news.xs4all.nl>,
> A. Dumas <alex...@dumas.fr.invalid> wrote:
>> Ja, of natuurlijk elke andere hoster waar je je DNS-records kunt
>> bewerken. Want naam->ip moet geloof ik eerst goed staan voordat je bij
>> Xs4all de reverse kunt instellen.
>
> Waarom zou je voor een website reverse DNS veranderen?
>
> Geen probleem als je graag een andere naam in reverse DNS wil hebben, maar
> het staat los van het eigenlijke probleem.
jouwDSLadres->jouwdomein bij Xs4all.
Jaap Keuter
Jan 7, 2017, 3:29:29 AM1/7/17
to
mijn self signed cert. ik streef naar een _oplossing_ van het
oorspronkelijke probleem.
Philip Homburg
Jan 7, 2017, 7:23:01 AM1/7/17
to
In article <587092e4$0$21443$e4fe...@news.xs4all.nl>,
je website host.
Als je reverse DNS aanpast, pas je dus de naam van je server aan. Prima,
naar dat staat helemaal los van je website.
Als je naar algemeen gebruik je website www.<domain> noemt, dan ga je
toch je reverse DNS niet op www.<domain> zetten?
A. Dumas <alex...@dumas.fr.invalid> wrote:
>> Geen probleem als je graag een andere naam in reverse DNS wil hebben, maar
>> het staat los van het eigenlijke probleem.
>
>Huh? Niet een andere, dezelfde. Jouwdomein->jouwDSLadres bij de hoster,
>jouwDSLadres->jouwdomein bij Xs4all.
De naam van je website heeft niets te maken met de naam van de server die
>> Geen probleem als je graag een andere naam in reverse DNS wil hebben, maar
>> het staat los van het eigenlijke probleem.
>
>Huh? Niet een andere, dezelfde. Jouwdomein->jouwDSLadres bij de hoster,
>jouwDSLadres->jouwdomein bij Xs4all.
je website host.
Als je reverse DNS aanpast, pas je dus de naam van je server aan. Prima,
naar dat staat helemaal los van je website.
Als je naar algemeen gebruik je website www.<domain> noemt, dan ga je
toch je reverse DNS niet op www.<domain> zetten?
Philip Homburg
Jan 7, 2017, 7:23:01 AM1/7/17
to
In article <5870a6e8$0$2772$e4fe...@newszilla.xs4all.nl>,
<hostname>.xs4all.nl
Je kan natuurlijk proberen de eerste te zijn op een maandag. Maar dat is
niet echt een algemene oplossing.
Dus in dit geval is de oplossing van het oorspronkelijke probleem om
gewoon bij een van de vele andere CA's een certificaat te kopen.
Jaap Keuter <em...@domain.com> wrote:
>Allemaal mooi, maar dit kwalificeer ik als 'work-arounds', net zoals
>mijn self signed cert. ik streef naar een _oplossing_ van het
>oorspronkelijke probleem.
Het is duidelijk dat letsencrypt niet bedoeld is voor situaties als
>Allemaal mooi, maar dit kwalificeer ik als 'work-arounds', net zoals
>mijn self signed cert. ik streef naar een _oplossing_ van het
>oorspronkelijke probleem.
<hostname>.xs4all.nl
Je kan natuurlijk proberen de eerste te zijn op een maandag. Maar dat is
niet echt een algemene oplossing.
Dus in dit geval is de oplossing van het oorspronkelijke probleem om
gewoon bij een van de vele andere CA's een certificaat te kopen.
Osiris
Jan 7, 2017, 9:01:42 AM1/7/17
to
On 07-01-17 13:00, Philip Homburg wrote:
> In article <5870a6e8$0$2772$e4fe...@newszilla.xs4all.nl>,
> Jaap Keuter <em...@domain.com> wrote:
>> Allemaal mooi, maar dit kwalificeer ik als 'work-arounds', net zoals
>> mijn self signed cert. ik streef naar een _oplossing_ van het
>> oorspronkelijke probleem.
>
> Het is duidelijk dat letsencrypt niet bedoeld is voor situaties als
> <hostname>.xs4all.nl
>
> Je kan natuurlijk proberen de eerste te zijn op een maandag. Maar dat is
> niet echt een algemene oplossing.
>
> Dus in dit geval is de oplossing van het oorspronkelijke probleem om
> gewoon bij een van de vele andere CA's een certificaat te kopen.
Of gewoon blijven proberen en hopen dat je vanzelf een keertje tussen de
> In article <5870a6e8$0$2772$e4fe...@newszilla.xs4all.nl>,
> Jaap Keuter <em...@domain.com> wrote:
>> Allemaal mooi, maar dit kwalificeer ik als 'work-arounds', net zoals
>> mijn self signed cert. ik streef naar een _oplossing_ van het
>> oorspronkelijke probleem.
>
> Het is duidelijk dat letsencrypt niet bedoeld is voor situaties als
> <hostname>.xs4all.nl
>
> Je kan natuurlijk proberen de eerste te zijn op een maandag. Maar dat is
> niet echt een algemene oplossing.
>
> Dus in dit geval is de oplossing van het oorspronkelijke probleem om
> gewoon bij een van de vele andere CA's een certificaat te kopen.
rate limits van Let's Encrypt doorkomt. *Sliding* window van 7 dagen,
dus zolang je eerder bent dan je concurrent zodra er een plekje
vrijkomt, zit je goed ;)
A. Dumas
Jan 7, 2017, 12:59:22 PM1/7/17
to
On 07/01/2017 13:05, Philip Homburg wrote:
> In article <587092e4$0$21443$e4fe...@news.xs4all.nl>,
> A. Dumas <alex...@dumas.fr.invalid> wrote:
>>> Geen probleem als je graag een andere naam in reverse DNS wil hebben, maar
>>> het staat los van het eigenlijke probleem.
>>
>> Huh? Niet een andere, dezelfde. Jouwdomein->jouwDSLadres bij de hoster,
>> jouwDSLadres->jouwdomein bij Xs4all.
>
> De naam van je website heeft niets te maken met de naam van de server die
> je website host.
>
> Als je reverse DNS aanpast, pas je dus de naam van je server aan. Prima,
> naar dat staat helemaal los van je website.
>
> Als je naar algemeen gebruik je website www.<domain> noemt, dan ga je
> toch je reverse DNS niet op www.<domain> zetten?
Ja. Als het niet nodig is voor het certificaat, dan hoef je die reverse
> In article <587092e4$0$21443$e4fe...@news.xs4all.nl>,
> A. Dumas <alex...@dumas.fr.invalid> wrote:
>>> Geen probleem als je graag een andere naam in reverse DNS wil hebben, maar
>>> het staat los van het eigenlijke probleem.
>>
>> Huh? Niet een andere, dezelfde. Jouwdomein->jouwDSLadres bij de hoster,
>> jouwDSLadres->jouwdomein bij Xs4all.
>
> De naam van je website heeft niets te maken met de naam van de server die
> je website host.
>
> Als je reverse DNS aanpast, pas je dus de naam van je server aan. Prima,
> naar dat staat helemaal los van je website.
>
> Als je naar algemeen gebruik je website www.<domain> noemt, dan ga je
> toch je reverse DNS niet op www.<domain> zetten?
niet in te stellen, nee. Maar de poster waar ik eerder op reageerde
bracht het op, dus ik dacht dat het wel nodig was.
Philip Homburg
Jan 7, 2017, 2:23:02 PM1/7/17
to
In article <58712c50$0$21444$e4fe...@news.xs4all.nl>,
Waar OP tegenaan loopt is dat letsencrypt alles binnen xs4all.nl als 1 domein
ziet en rate limiting toepast alsof al die requests bij 1 domein horen.
Letsencrypt doet niets met reverse DNS. Je geeft op voor welk domein je een
certificaat wil hebben en letsencrypt controleert of dat domein ook echt
van jouw is.
Maar ze hebben rate limits ingesteld om te voorkomen dat mensen absurd grote
hoeveelheden certificaten voor 1 domein aan gaan vragen.
Waarschijnlijk wil er bijna niemand een certificaat voor <hostname>.<provider>
want dat wordt niet echt ondersteund. Er is wel een white list, maar het
is niet duidelijk of die voor xs4all.nl bedoeld is.
Maar het kan best zijn dat onder de huidige omstandigheden www.xs4all.nl
ook niet echt veilig is. Als ik tijd heb zal ik eens wat experimenteren.
ziet en rate limiting toepast alsof al die requests bij 1 domein horen.
Letsencrypt doet niets met reverse DNS. Je geeft op voor welk domein je een
certificaat wil hebben en letsencrypt controleert of dat domein ook echt
van jouw is.
Maar ze hebben rate limits ingesteld om te voorkomen dat mensen absurd grote
hoeveelheden certificaten voor 1 domein aan gaan vragen.
Waarschijnlijk wil er bijna niemand een certificaat voor <hostname>.<provider>
want dat wordt niet echt ondersteund. Er is wel een white list, maar het
is niet duidelijk of die voor xs4all.nl bedoeld is.
Maar het kan best zijn dat onder de huidige omstandigheden www.xs4all.nl
ook niet echt veilig is. Als ik tijd heb zal ik eens wat experimenteren.
Jaap Keuter
Jan 8, 2017, 8:18:30 AM1/8/17
to
On 2017-01-07 12:00:57 +0000, Philip Homburg said:
> In article <5870a6e8$0$2772$e4fe...@newszilla.xs4all.nl>,
> Jaap Keuter <em...@domain.com> wrote:
>> Allemaal mooi, maar dit kwalificeer ik als 'work-arounds', net zoals
>> mijn self signed cert. ik streef naar een _oplossing_ van het
>> oorspronkelijke probleem.
>
> Het is duidelijk dat letsencrypt niet bedoeld is voor situaties als
> <hostname>.xs4all.nl
Ehm, da's onjuist. Zij beschrijven dit op
> In article <5870a6e8$0$2772$e4fe...@newszilla.xs4all.nl>,
> Jaap Keuter <em...@domain.com> wrote:
>> Allemaal mooi, maar dit kwalificeer ik als 'work-arounds', net zoals
>> mijn self signed cert. ik streef naar een _oplossing_ van het
>> oorspronkelijke probleem.
>
> Het is duidelijk dat letsencrypt niet bedoeld is voor situaties als
> <hostname>.xs4all.nl
https://letsencrypt.org/docs/rate-limits/ in de paragraaf over
Certificates per Registered Domain.
"We use the Public Suffix List to calculate the registered domain.".
Dus als "xs4all.nl" in de Public Sufffix List wordt opgenomen kan
iedereen met een XS4ALL subdomain een Let's Encrypt certificate voor
zijn subdomain aanvragen.
Jaap Keuter
Jan 8, 2017, 8:23:29 AM1/8/17
to
steeds korter worden om de ander maar voor te blijven, totdat de
refresh rate van Let's Encrypt de ondergrens stelt. Hit & miss is niet
helemaal wat ik als oplossing zie.
Philip Homburg
Jan 8, 2017, 9:23:01 AM1/8/17
to
In article <58723c10$0$2854$e4fe...@newszilla.xs4all.nl>,
meteen de xs4all website. Hoewel dat wel beter zou zijn, nu lekken er
cookies.
Ik dacht dat de public suffix list voor TLDs etc was. Maar je hebt
gelijk, xs4all kan prima zichzelf in de 'PRIVATE' sectie registreren.
Jaap Keuter <em...@domain.com> wrote:
>Ehm, da's onjuist. Zij beschrijven dit op
>https://letsencrypt.org/docs/rate-limits/ in de paragraaf over
>Certificates per Registered Domain.
>"We use the Public Suffix List to calculate the registered domain.".
>Dus als "xs4all.nl" in de Public Sufffix List wordt opgenomen kan
>iedereen met een XS4ALL subdomain een Let's Encrypt certificate voor
>zijn subdomain aanvragen.
Als xs4all zich zelf op de public suffix list plaatst dan sloopt dat
>Ehm, da's onjuist. Zij beschrijven dit op
>https://letsencrypt.org/docs/rate-limits/ in de paragraaf over
>Certificates per Registered Domain.
>"We use the Public Suffix List to calculate the registered domain.".
>Dus als "xs4all.nl" in de Public Sufffix List wordt opgenomen kan
>iedereen met een XS4ALL subdomain een Let's Encrypt certificate voor
>zijn subdomain aanvragen.
meteen de xs4all website. Hoewel dat wel beter zou zijn, nu lekken er
cookies.
Ik dacht dat de public suffix list voor TLDs etc was. Maar je hebt
gelijk, xs4all kan prima zichzelf in de 'PRIVATE' sectie registreren.
Miquel van Smoorenburg
Jan 8, 2017, 9:52:40 AM1/8/17
to
In article <0djphg6d8rvfv9ja1tou4mnvk0@inews_id.stereo.hq.phicoh.net>,
xs4all.nl. Daar wordt momenteel over nagedacht (niet voor de eerste
keer). Ik heb voorgesteld om '<klantdomein>.xs4.nl' te gaan gebruiken.
xs4.nl zou dan in de public suffix list opgenomen kunnen worden.
Evt dan weer eens proberen om een IPv6 hostname editor in de "mijn"
omgeving te krijgen, met meerdere hostnames onder <klantdomein>.xs4.nl.
(xs4.nl omdat xs4all die heeft, niet gebruikt wordt, en lekker kort is)
Mike.
Philip Homburg <phi...@ue.aioy.eu> wrote:
>In article <58723c10$0$2854$e4fe...@newszilla.xs4all.nl>,
>Jaap Keuter <em...@domain.com> wrote:
>>Ehm, da's onjuist. Zij beschrijven dit op
>>https://letsencrypt.org/docs/rate-limits/ in de paragraaf over
>>Certificates per Registered Domain.
>>"We use the Public Suffix List to calculate the registered domain.".
>>Dus als "xs4all.nl" in de Public Sufffix List wordt opgenomen kan
>>iedereen met een XS4ALL subdomain een Let's Encrypt certificate voor
>>zijn subdomain aanvragen.
>
>Als xs4all zich zelf op de public suffix list plaatst dan sloopt dat
>meteen de xs4all website. Hoewel dat wel beter zou zijn, nu lekken er
>cookies.
>
>Ik dacht dat de public suffix list voor TLDs etc was. Maar je hebt
>gelijk, xs4all kan prima zichzelf in de 'PRIVATE' sectie registreren.
Nog beter is om een ander domein te hebben voor klant-hostnames ipv
>In article <58723c10$0$2854$e4fe...@newszilla.xs4all.nl>,
>Jaap Keuter <em...@domain.com> wrote:
>>Ehm, da's onjuist. Zij beschrijven dit op
>>https://letsencrypt.org/docs/rate-limits/ in de paragraaf over
>>Certificates per Registered Domain.
>>"We use the Public Suffix List to calculate the registered domain.".
>>Dus als "xs4all.nl" in de Public Sufffix List wordt opgenomen kan
>>iedereen met een XS4ALL subdomain een Let's Encrypt certificate voor
>>zijn subdomain aanvragen.
>
>Als xs4all zich zelf op de public suffix list plaatst dan sloopt dat
>meteen de xs4all website. Hoewel dat wel beter zou zijn, nu lekken er
>cookies.
>
>Ik dacht dat de public suffix list voor TLDs etc was. Maar je hebt
>gelijk, xs4all kan prima zichzelf in de 'PRIVATE' sectie registreren.
xs4all.nl. Daar wordt momenteel over nagedacht (niet voor de eerste
keer). Ik heb voorgesteld om '<klantdomein>.xs4.nl' te gaan gebruiken.
xs4.nl zou dan in de public suffix list opgenomen kunnen worden.
Evt dan weer eens proberen om een IPv6 hostname editor in de "mijn"
omgeving te krijgen, met meerdere hostnames onder <klantdomein>.xs4.nl.
(xs4.nl omdat xs4all die heeft, niet gebruikt wordt, en lekker kort is)
Mike.
Luuk
Jan 8, 2017, 11:21:57 AM1/8/17
to
wat traag te gaan ... ;)
(om toch maar weer wat te zeuren te hebben)
maar, ... , ik stem voor! (als ik hiervoor mocht stemmen)
A. Dumas
Jan 8, 2017, 11:31:08 AM1/8/17
to
On 08/01/2017 15:51, Miquel van Smoorenburg wrote:
> Nog beter is om een ander domein te hebben voor klant-hostnames ipv
> xs4all.nl. Daar wordt momenteel over nagedacht (niet voor de eerste
> keer). Ik heb voorgesteld om '<klantdomein>.xs4.nl' te gaan gebruiken.
> xs4.nl zou dan in de public suffix list opgenomen kunnen worden.
>
> Evt dan weer eens proberen om een IPv6 hostname editor in de "mijn"
> omgeving te krijgen, met meerdere hostnames onder <klantdomein>.xs4.nl.
>
> (xs4.nl omdat xs4all die heeft, niet gebruikt wordt, en lekker kort is)
Leuk, dat zou mooi zijn.
> Nog beter is om een ander domein te hebben voor klant-hostnames ipv
> xs4all.nl. Daar wordt momenteel over nagedacht (niet voor de eerste
> keer). Ik heb voorgesteld om '<klantdomein>.xs4.nl' te gaan gebruiken.
> xs4.nl zou dan in de public suffix list opgenomen kunnen worden.
>
> Evt dan weer eens proberen om een IPv6 hostname editor in de "mijn"
> omgeving te krijgen, met meerdere hostnames onder <klantdomein>.xs4.nl.
>
> (xs4.nl omdat xs4all die heeft, niet gebruikt wordt, en lekker kort is)
MM
Jan 9, 2017, 10:50:25 AM1/9/17
to
On 5-12-2016 14:08, Daniël Mostertman wrote:
> Vanaf vandaag hebben we beveiligde verbindingen mogelijk gemaakt voor al
> onze Webhosting-klanten! Klanten hoeven hier zelf niets voor in te stellen:
> Het staat standaard voor al onze klanten aan.
>
knip>
> Vanaf vandaag hebben we beveiligde verbindingen mogelijk gemaakt voor al
> onze Webhosting-klanten! Klanten hoeven hier zelf niets voor in te stellen:
> Het staat standaard voor al onze klanten aan.
>
> Mochten er nog andere vragen zijn, dan hoor ik ze graag.
>
> --
>
> Daniël Mostertman
> XS4ALL Systeembeheer
>
Ik wil toch een zetje geven voor een goedkopere manier van het
registreren van een NL domein voor particulieren. Net nog een paar
oudjes verhuist van Ziggo naar Xs4all en dan komt het gezeur van het
doorgeven van het nieuwe e-mail adres.
Om dit te voorkomen heb ik een NL domein aangevraagd bij een andere
partij want Xs4all zat hier erg hoog met de prijs. Zij hebben geen
DNSSEC nu maar wel Letsencrypt, wat met 1 klik aan te zetten was.
Wat doen de oudjes nu met het domein. Eigenlijk alleen het doorzenden
van de e-mail en ik heb enkele adressen aangemaakt voor privé,
nieuwsbrieven en reclame meuk zodat dat meteen al in de juiste mailbox
geplaatst wordt en niet de inbox vervuild.
Het zijn directe forwards zodat de spam detectie van Xs4all werkt. De
forwards gaan naar de mailbox van de oudjes bij Xs4all en zij verzenden
van daaruit of via een lokaal mailprogramma op de PC hun mails.
Nu kost dit ongeveer 11 euro in het jaar. Liever had ik dit ook, via
Xs4all laten afnemen maar de huidige domein registratie is te prijzig
voor zo'n eenvoudige opzet.
In kort is het koppelen van de homepage aan het domein en het forwarden
van de mail naar de mailbox.
Dit kan dan bestaan naast xs4.nl wat Mike, welkom terug!, voorstelt.
Rob
Jan 9, 2017, 12:24:36 PM1/9/17
to
MM <m...@invalid.xs4all.nl> wrote:
> Om dit te voorkomen heb ik een NL domein aangevraagd bij een andere
> partij want Xs4all zat hier erg hoog met de prijs. Zij hebben geen
> DNSSEC nu maar wel Letsencrypt, wat met 1 klik aan te zetten was.
>
> Wat doen de oudjes nu met het domein. Eigenlijk alleen het doorzenden
> van de e-mail en ik heb enkele adressen aangemaakt voor privé,
> nieuwsbrieven en reclame meuk zodat dat meteen al in de juiste mailbox
> geplaatst wordt en niet de inbox vervuild.
Maar dat kun je niet met alleen een domein, dan moet je ook nog een
> Om dit te voorkomen heb ik een NL domein aangevraagd bij een andere
> partij want Xs4all zat hier erg hoog met de prijs. Zij hebben geen
> DNSSEC nu maar wel Letsencrypt, wat met 1 klik aan te zetten was.
>
> Wat doen de oudjes nu met het domein. Eigenlijk alleen het doorzenden
> van de e-mail en ik heb enkele adressen aangemaakt voor privé,
> nieuwsbrieven en reclame meuk zodat dat meteen al in de juiste mailbox
> geplaatst wordt en niet de inbox vervuild.
mailserver hebben. Wat je eigenlijk wilt is dat bij een XS4ALL account
standaard een (al dan niet extern geregistreerd) domein kan worden
opgegeven voor het ontvangen van mail. Als dat niet kan ben je met
een domein nog niet veel verder.
Philip Homburg
Jan 9, 2017, 12:53:00 PM1/9/17
to
In article <5873b13f$0$21493$e4fe...@news.xs4all.nl>,
dan je provider (mijn voorkeur is zelfs een registrar die alleen het
domein registreert) is dat bij een verhuizing er niets mis gaat met je
domein.
Stel je domein werd door Ziggo gehost en je verhuist naar Xs4all. Als je
dan bij Ziggo het internet gedeelte opzegt en zij de-registreren ook je
domein dan heb je opeens een enorm probleem.
Dus de huidige situatie is op lange termijn betrouwbaarder.
MM <m...@invalid.xs4all.nl> wrote:
>Nu kost dit ongeveer 11 euro in het jaar. Liever had ik dit ook, via
>Xs4all laten afnemen maar de huidige domein registratie is te prijzig
>voor zo'n eenvoudige opzet.
Het grote voordeel van het hosten van je domein bij een andere partij
>Nu kost dit ongeveer 11 euro in het jaar. Liever had ik dit ook, via
>Xs4all laten afnemen maar de huidige domein registratie is te prijzig
>voor zo'n eenvoudige opzet.
dan je provider (mijn voorkeur is zelfs een registrar die alleen het
domein registreert) is dat bij een verhuizing er niets mis gaat met je
domein.
Stel je domein werd door Ziggo gehost en je verhuist naar Xs4all. Als je
dan bij Ziggo het internet gedeelte opzegt en zij de-registreren ook je
domein dan heb je opeens een enorm probleem.
Dus de huidige situatie is op lange termijn betrouwbaarder.
Rob
Jan 9, 2017, 12:56:24 PM1/9/17
to
Philip Homburg <phi...@ue.aioy.eu> wrote:
> Het grote voordeel van het hosten van je domein bij een andere partij
> dan je provider (mijn voorkeur is zelfs een registrar die alleen het
> domein registreert) is dat bij een verhuizing er niets mis gaat met je
> domein.
>
> Stel je domein werd door Ziggo gehost en je verhuist naar Xs4all. Als je
> dan bij Ziggo het internet gedeelte opzegt en zij de-registreren ook je
> domein dan heb je opeens een enorm probleem.
Dat ligt er aan of je het zelf op je naam hebt of dat je zo'n goedkope
> Het grote voordeel van het hosten van je domein bij een andere partij
> dan je provider (mijn voorkeur is zelfs een registrar die alleen het
> domein registreert) is dat bij een verhuizing er niets mis gaat met je
> domein.
>
> Stel je domein werd door Ziggo gehost en je verhuist naar Xs4all. Als je
> dan bij Ziggo het internet gedeelte opzegt en zij de-registreren ook je
> domein dan heb je opeens een enorm probleem.
hoster hebt die het op zijn eigen naam registreert en het dan aan jou
beschikbaar stelt.
Als het op je eigen naam staat dan kan er weinig gebeuren, zeker met
een .nl die nog een tijd bevroren wordt nadat ie gederegistreerd is.
Osiris
Jan 9, 2017, 1:17:57 PM1/9/17
to
Rob
Jan 9, 2017, 1:40:47 PM1/9/17
to
Miquel van Smoorenburg <mik...@xs4all.nederland.invalid> wrote:
> In article <0djphg6d8rvfv9ja1tou4mnvk0@inews_id.stereo.hq.phicoh.net>,
> Philip Homburg <phi...@ue.aioy.eu> wrote:
>>In article <58723c10$0$2854$e4fe...@newszilla.xs4all.nl>,
>>Jaap Keuter <em...@domain.com> wrote:
>>>Ehm, da's onjuist. Zij beschrijven dit op
>>>https://letsencrypt.org/docs/rate-limits/ in de paragraaf over
>>>Certificates per Registered Domain.
>>>"We use the Public Suffix List to calculate the registered domain.".
>>>Dus als "xs4all.nl" in de Public Sufffix List wordt opgenomen kan
>>>iedereen met een XS4ALL subdomain een Let's Encrypt certificate voor
>>>zijn subdomain aanvragen.
>>
>>Als xs4all zich zelf op de public suffix list plaatst dan sloopt dat
>>meteen de xs4all website. Hoewel dat wel beter zou zijn, nu lekken er
>>cookies.
>>
>>Ik dacht dat de public suffix list voor TLDs etc was. Maar je hebt
>>gelijk, xs4all kan prima zichzelf in de 'PRIVATE' sectie registreren.
>
> Nog beter is om een ander domein te hebben voor klant-hostnames ipv
> xs4all.nl. Daar wordt momenteel over nagedacht (niet voor de eerste
> keer). Ik heb voorgesteld om '<klantdomein>.xs4.nl' te gaan gebruiken.
> xs4.nl zou dan in de public suffix list opgenomen kunnen worden.
Hopelijk met een of andere vorm van migratie...
> In article <0djphg6d8rvfv9ja1tou4mnvk0@inews_id.stereo.hq.phicoh.net>,
> Philip Homburg <phi...@ue.aioy.eu> wrote:
>>In article <58723c10$0$2854$e4fe...@newszilla.xs4all.nl>,
>>Jaap Keuter <em...@domain.com> wrote:
>>>Ehm, da's onjuist. Zij beschrijven dit op
>>>https://letsencrypt.org/docs/rate-limits/ in de paragraaf over
>>>Certificates per Registered Domain.
>>>"We use the Public Suffix List to calculate the registered domain.".
>>>Dus als "xs4all.nl" in de Public Sufffix List wordt opgenomen kan
>>>iedereen met een XS4ALL subdomain een Let's Encrypt certificate voor
>>>zijn subdomain aanvragen.
>>
>>Als xs4all zich zelf op de public suffix list plaatst dan sloopt dat
>>meteen de xs4all website. Hoewel dat wel beter zou zijn, nu lekken er
>>cookies.
>>
>>Ik dacht dat de public suffix list voor TLDs etc was. Maar je hebt
>>gelijk, xs4all kan prima zichzelf in de 'PRIVATE' sectie registreren.
>
> Nog beter is om een ander domein te hebben voor klant-hostnames ipv
> xs4all.nl. Daar wordt momenteel over nagedacht (niet voor de eerste
> keer). Ik heb voorgesteld om '<klantdomein>.xs4.nl' te gaan gebruiken.
> xs4.nl zou dan in de public suffix list opgenomen kunnen worden.
> Evt dan weer eens proberen om een IPv6 hostname editor in de "mijn"
> omgeving te krijgen, met meerdere hostnames onder <klantdomein>.xs4.nl.
de ingestelde toplevel hostnaam (afleveren in een XS4ALL mailbox of
doorsturen naar een server van de klant, ook als het geen .xs4.nl is).
0 new messages