Waarom zijn alle payservers zo zwak beveiligd met SSL?

[Resilldoux]

Hallo,

Ik zou graag willen weten waarom elke usenet payserver (ik noem ze voor het gemak even providers) allemaal zwak beveiligde servers draaien? Hier zijn wat Qualys SSL Labs links voor de providers op deze pagina: https://www.binaries4all.nl/payservers/

XLned: https://www.ssllabs.com/s...yze.html?d=news.xlned.com
Eweka: https://www.ssllabs.com/s...html?d=sslreader.eweka.nl
Pure Usenet: https://www.ssllabs.com/s...html?d=news.pureusenet.nl
Yabnews: https://www.ssllabs.com/s...ze.html?d=news.yabnews.nl
VoordeligUsenet: https://www.ssllabs.com/s...&ignoreMismatch=on&latest
Extreme Usenet: https://www.ssllabs.com/s...s.extremeusenet.nl&latest
Usenet.pro: https://www.ssllabs.com/s...=pro.sslusenet.com&latest
UsenetBucket: https://www.ssllabs.com/s...d=reader.usenetbucket.com
123Usenet: https://www.ssllabs.com/s...tml?d=reader.123usenet.nl
NextGenNews: https://www.ssllabs.com/s...&ignoreMismatch=on&latest (certificaat is al bijna 2 jaar verlopen, maar heeft samen met UsenetServer als enige geen SSL2! Maar wel weer 3...)
Newshosting: https://www.ssllabs.com/s...ws.newshosting.com&latest
UsenetServer: https://www.ssllabs.com/s...s.usenetserver.com&latest (Geen SSL 2! Maar wel weer SSL 3...)

(Bijna) alle providers vermelden hostnames op hun site de niet altijd overeen komen de naam in het certificaat, ondersteunen zwakke protocollen (zelfs SSL 2 en 3), zijn mede daarom vatbaar voor man-in-the-middle aanvallen (FREAK, POODLE), ondersteunen zwakke versleutelingen (RC4, zoals Jacob Appelbaum daar ons toentertijd via Twitter op wees), geen PFS, maar dan wel weer TLS_FALLBACK_SCSV zodat downgrade aanvallen worden getackeld. Echter, clients die standaard verbinden met verouderde protocollen en versleutelingen zijn dus wel weer automatisch vatbaar...

Veel sites vermelden hun hostnames op halfgebakken oude handleidingen voor het instellen van GrabIt / Spotnet (ja echt...) en dergelijke clients. Ik zag zelfs nog ergens een handleiding voor het installeren van FTD en daar moest ik toch wel even een nostalgisch traantje om laten... Even goed, daar haalde ik bovenstaande hostnames vandaan.

Waarom is dit toch? Is het echt puur voor compatability redenen om verouderde clients die klanten nog gebruiken te ondersteunen? Geld speelt altijd wel een rol, maar weegt het aantal klanten dat alleen nog SSL 2 of 3 ondersteund, hoger op dan het waarborgen van veiligheid zoals elke provider daar trots mee te koop loopt op hun web sites? Ik vind het zeer merkwaardig.

Uitkijkend naar jullie reacties.

[Pistolebob]

Werkt dat Usenet nog een beetje?
Ik dacht dat het steeds moeilijker werd om succesvol iets binnen te halen ivm geautomatiseerde DMCA takedowns.

[Bartske]

Pistolebob schreef op vrijdag 19 juni 2015 @ 12:45:
Werkt dat Usenet nog een beetje?
Ik dacht dat het steeds moeilijker werd om succesvol iets binnen te halen ivm geautomatiseerde DMCA takedowns.

offtopic:
Het werkt nog prima, je moet er alleen snel bij zijn. Als je een nas hebt met sickbeard en couchpotato die gewoon kijkt wanneer er iets beschikbaar komt kun je het altijd optijd binnenhalen. Maar wacht je een dag dan is er best kans dat iets al weggehaald is, zeker met populaire series.

[WeaZuL]

Goede vraag, ik denk zelf dat deze providers het aanbieden van deze dienst via sterk beveiligde kanalen niet (graag) zien als onderdeel van hun core business? Ik verwacht dat de kosten aan encryptie/decryptie in het geval van sterke versleuteling vs de enorme hoeveelheid traffic niet in verhouding staan tot het huidige verdien model.

Ik las bijvoorbeeld in een ander topic waar aanbieders van VPN diensten, die van het aanbieden van beveiligde kanalen hun corebusiness hebben gemaakt, ook niet bepaald staan te springen om klanten die enorme hoeveelheden verkeer (torrents) via hun servers te laten lopen.

[ Voor 36% gewijzigd door WeaZuL op 19-06-2015 13:47 ]

[Resilldoux]

WeaZul, dat zou goed kunnen. Ik vind het jammer dat dit kennelijk ook het geval is, in elk geval bij Hitnews. Na aanleiding van een e-mail dat ik naar hen stuurde, kreeg ik na twee weken reactie:

Hi Guido,

My apologies for the late reply. I have sent this to our techs and have yet to hear from them.
Many of our customers use old news clients. To make sure they are still able to connect older versions need to be supported by our system.
Having said that other safety measures are in place.

I would like to thank you for your elaborate email by giving you some extra time on your account. May i ask for your username to do so?


Best regards,
Support Team

Merkwaardig dat ik nu zo goed als omgekocht wordt, niet waar? Ik ben benieuwd naar andere providers...

[Soldaatje]

Encryptie kost CPU-power, en dus geld, dus daar zouden ze misschien op willen bezuinigen?

[Eagle Creek]

Lijkt me niet dat een slechte implementatie van SSL op enige wijze op een effectieve en doeltreffende manier CPU-power bezuinigt.

Wat is er mis met Grabit?

[CH4OS]

WeaZuL schreef op vrijdag 19 juni 2015 @ 13:03:
Goede vraag, ik denk zelf dat deze providers het aanbieden van deze dienst via sterk beveiligde kanalen niet (graag) zien als onderdeel van hun core business? Ik verwacht dat de kosten aan encryptie/decryptie in het geval van sterke versleuteling vs de enorme hoeveelheid traffic niet in verhouding staan tot het huidige verdien model.

Ik las bijvoorbeeld in een ander topic waar aanbieders van VPN diensten, die van het aanbieden van beveiligde kanalen hun corebusiness hebben gemaakt, ook niet bepaald staan te springen om klanten die enorme hoeveelheden verkeer (torrents) via hun servers te laten lopen.

Als je niet zit te wachten op veel (binary) dataverkeer binnen Usenet, moet je geen usenetprovider worden, zo simpel is het. Ik denk dat 90% (zo niet meer) van de usenet gebruikers het juist gebruiken voor de binaries.

[WeaZuL]

CptChaos schreef op donderdag 25 juni 2015 @ 23:38:
[...]
Als je niet zit te wachten op veel (binary) dataverkeer binnen Usenet, moet je geen usenetprovider worden, zo simpel is het. Ik denk dat 90% (zo niet meer) van de usenet gebruikers het juist gebruiken voor de binaries.

De keus dat jij zonder of met relatieve zwakke encryptie (binary) data up/download ligt toch echt bij jezelf (de klant). Sterke encryptie is relatief duur, dat voelt de provider en berekend die kosten vervolgens door naar de klant. Indien de klant ervoor wil betalen is het geen punt, ik denk echter dat het merendeel van de afnemers meer om de prijs/snelheid/retentie verhouding geeft dan om het aangeboden security niveau. "Oh, ssl available?, Check".

[ Voor 3% gewijzigd door WeaZuL op 26-06-2015 00:19 ]

[Fish]

is het niet gewoon omdat dit tooltje een https verbinding probeert te openen en een timeout geeft. in plaats van dat je werkelijk met een nntp server verbind ?

[Resilldoux]

Eagle Creek schreef op donderdag 25 juni 2015 @ 23:37:
Lijkt me niet dat een slechte implementatie van SSL op enige wijze op een effectieve en doeltreffende manier CPU-power bezuinigt.

Wat is er mis met Grabit?

offtopic:
Ik associeer het inderdaad een beetje onterecht met verouderde software. Excuses. :-)

[Resilldoux]

Fish schreef op vrijdag 26 juni 2015 @ 00:26:
is het niet gewoon omdat dit tooltje een https verbinding probeert te openen en een timeout geeft. in plaats van dat je werkelijk met een nntp server verbind ?

Scherp, maar als ik bijvoorbeeld handmatig een SSL 3 verbinding forceer naar een news server met:

openssl s_client -connect <host>:<port> -ssl3

kom ik op gelijksoortige resultaten uit. Wellicht is het mogelijk om ook specifieke ciphers te testen, maar zo ver heb ik mij hier nog niet in verdiept. Deel gerust bevindingen!

[Fish]

Resilldoux schreef op vrijdag 26 juni 2015 @ 00:33:
[...]

offtopic:
Ik associeer het inderdaad een beetje onterecht met verouderde software. Excuses. :-)

Wat is er mis met grabit ?
De helft van de tijd gaat het op zijn gat en de rar bestanden worden niet uitgepakt. sta je weer manueel te quickparren. rss feeds. kan dat al ? Hoe lanf zit hij nu al op 1.7.3b
waar blijft 2.0?
api toegang ?
nog steeds in beta na vele jaren


Sabnzbd+ is gewoon koning, nooit, maar dan ook nooit problemen


GrabIt 1.5.0 Beta Nov 21, 2004 0.00 B
GrabIt 1.5.1 Beta Nov 21, 2004 0.00 B
GrabIt 1.5.2 Beta Mar 28, 2005 0.00 B
GrabIt 1.5.3 Beta May 22, 2005 0.00 B
GrabIt 1.6.0 Beta Mar 27, 2006 0.00 B
GrabIt 1.6.1 Beta May 29, 2006 0.00 B
GrabIt 1.6.2 Beta Jun 11, 2006 0.00 B
GrabIt 1.7.0 Beta May 5, 2007 0.00 B
GrabIt 1.7.1 Beta May 6, 2007 0.00 B
GrabIt 1.7.2 Beta Aug 9, 2008 0.00 B
GrabIt 1.7.2 Beta 2 Aug 27, 2008 0.00 B
GrabIt 1.7.2 Beta 3 Sep 16, 2008 0.00 B
GrabIt 1.7.2 Beta 4 Apr 30, 2009 0.00 B
GrabIt 1.7.2 Beta 5 Sep 11, 2011 0.00 B
GrabIt 1.7.2 Beta 6 Oct 1, 2011 0.00 B

[ Voor 37% gewijzigd door Fish op 26-06-2015 00:51 ]

[Resilldoux]

Fish schreef op vrijdag 26 juni 2015 @ 00:48:
[...]

Wat is er mis met grabit ?
De helft van de tijd gaat het op zijn gat en de rar bestanden worden niet uitgepakt. sta je weer manueel te quickparren. rss feeds. kan dat al ? Hoe lanf zit hij nu al op 1.7.3b
waar blijft 2.0?
api toegang ?

Sabnzbd+ is gewoon koning, nooit, maar dan ook nooit problemen

Ah, I stand corrected. Ikzelf gebruikte inderdaad ook al jaren SABnzbd+ en zijn voorganger SABnzbd, voordat het geforked werd. De laatste jaren merk ik echter dat het project een beetje aan het stagneren is. Weinig updates, weinig nieuwe features en daarom ben ik overgestapt naar NZBGet. Minder performance impact en dus meer geschikt voor ARM apparaten en ik kan zelf expliciet opgeven met welke ciphers ik verbind naar een news server (alhoewel ik dit laatste niet meer heb gecheckt bij SABnzbd+, dus ik weet niet of dit een gegronde reden is)

[Fish]

SSL Type
Normally you use V23. For some ISP-s you may need either V2 or V3 to get optimal speed.

Ik kan eigenlijk niet bedenken wat erbij zou moeten komen als feature. (buiten de core functie, het downloaden en verwerken van de downloads)

[ Voor 40% gewijzigd door Fish op 26-06-2015 01:11 ]

[CH4OS]

WeaZuL schreef op vrijdag 26 juni 2015 @ 00:17:
[...]


De keus dat jij zonder of met relatieve zwakke encryptie (binary) data up/download ligt toch echt bij jezelf (de klant). Sterke encryptie is relatief duur, dat voelt de provider en berekend die kosten vervolgens door naar de klant. Indien de klant ervoor wil betalen is het geen punt, ik denk echter dat het merendeel van de afnemers meer om de prijs/snelheid/retentie verhouding geeft dan om het aangeboden security niveau. "Oh, ssl available?, Check".

Wat heeft de encryptie te maken met dataverkeer, waar ik het over heb? Dataverkeer is de grootste kostenpost voor providers namelijk.

[ Voor 4% gewijzigd door CH4OS op 26-06-2015 07:56 ]

[Eagle Creek]

Fish schreef op vrijdag 26 juni 2015 @ 00:48:
[...]

Wat is er mis met grabit ?
De helft van de tijd gaat het op zijn gat en de rar bestanden worden niet uitgepakt. sta je weer manueel te quickparren. rss feeds. kan dat al ? Hoe lanf zit hij nu al op 1.7.3b
waar blijft 2.0?
api toegang ?
nog steeds in beta na vele jaren

Tja, geen idee. Ik download vrijwel nooit en heb Grabit altijd met tevredenheid kunnen gebruiken.
Maar denk dat m'n laatste gebruik twee/drie jaar geleden is..

[WeaZuL]

CptChaos schreef op vrijdag 26 juni 2015 @ 07:55:
[...]
Wat heeft de encryptie te maken met dataverkeer, waar ik het over heb? Dataverkeer is de grootste kostenpost voor providers namelijk.

Usenet providers bedoel je dan? Ik kan mij voorstellen dat wanneer deze usenet providers ook nog eens sterke encryptie aanbieden icm dit dataverkeer dat de kosten (o.a. cpucycles) enkel nog meer zullen stijgen.

[CH4OS]

WeaZuL schreef op vrijdag 26 juni 2015 @ 12:04:
Usenet providers bedoel je dan? Ik kan mij voorstellen dat wanneer deze usenet providers ook nog eens sterke encryptie aanbieden icm dit dataverkeer dat de kosten (o.a. cpucycles) enkel nog meer zullen stijgen.

Ja, de Usenet providers zelf zoals ik al schreef in mijn eerste reactie. Daarnaast zijn de implementaties van SSL in de diverse readers ook niet top-notch. Een goede beveiliging begint daarnaast met een valid en signed certificate en dat bieden de meesten niet (omdat de clients er ook niet op checken).

[ Voor 9% gewijzigd door CH4OS op 26-06-2015 13:52 ]

[Fish]

Resilldoux schreef op vrijdag 26 juni 2015 @ 00:43:
[...]

Scherp, maar als ik bijvoorbeeld handmatig een SSL 3 verbinding forceer naar een news server met:


[...]


kom ik op gelijksoortige resultaten uit. Wellicht is het mogelijk om ook specifieke ciphers te testen, maar zo ver heb ik mij hier nog niet in verdiept. Deel gerust bevindingen!

F:\Program Files\OpenSsl>openssl s_client -connect sslreader.eweka.nl:563 -ssl3
Loading 'screen' into random state - done
CONNECTED(0000017C)
depth=2 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
verify error:num=19:self signed certificate in certificate chain
---
Certificate chain
0 s:/OU=Domain Control Validated/OU=PositiveSSL Wildcard/CN=*.eweka.nl
i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=PositiveSSL CA 2
1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=PositiveSSL CA 2
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
2 s:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIE9jCCA96gAwIBAgIRAPiIhr7OUu9W8fUP7PjDGBQwDQYJKoZIhvcNAQEFBQAw
czELMAkGA1UEBhMCR0IxGzAZBgNVBAgTEkdyZWF0ZXIgTWFuY2hlc3RlcjEQMA4G
A1UEBxMHU2FsZm9yZDEaMBgGA1UEChMRQ09NT0RPIENBIExpbWl0ZWQxGTAXBgNV
BAMTEFBvc2l0aXZlU1NMIENBIDIwHhcNMTMwMzIwMDAwMDAwWhcNMTgwMzE5MjM1
OTU5WjBXMSEwHwYDVQQLExhEb21haW4gQ29udHJvbCBWYWxpZGF0ZWQxHTAbBgNV
BAsTFFBvc2l0aXZlU1NMIFdpbGRjYXJkMRMwEQYDVQQDFAoqLmV3ZWthLm5sMIIB
IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAv1hT1zfZBnyAojq2eCfdpc+d
rBgQRyeiPLzySE+3AmXjwIAZjCiv9HkC1Ioq9AYV2NWEJUAYwznE3WeWwR8m1OHV
97T1HYxrBCkS0PfYwMnW2SfQWLu+ea4w7UF35vR//VunnF1CfC4jSPFY1uJFcqTx
UtUxlMXALY3MX34pCJFjQYD59eUDHQe68ywJq3STQe0oSLHW14mFNVFhyTaduVPA
iE0PGJr2JNmiPpoYMCRreJ+V9Olt6ZTtmepGFG7/+mSkDqnHNUDet02ALMXSc7Ua
XH40uL7koRcl6Q0vCz2RIrqif4XpURu+30iTDfQQ7/XB+XgARJ1dOslxRCUPvwID
AQABo4IBnzCCAZswHwYDVR0jBBgwFoAUmeRAX2sUXj4F2d3TY1T8Yrj3AKwwHQYD
VR0OBBYEFABihd/gtX6b4Xfek/tdJOlGmqz1MA4GA1UdDwEB/wQEAwIFoDAMBgNV
HRMBAf8EAjAAMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEFBQcDAjBQBgNVHSAE
STBHMDsGCysGAQQBsjEBAgIHMCwwKgYIKwYBBQUHAgEWHmh0dHA6Ly93d3cucG9z
aXRpdmVzc2wuY29tL0NQUzAIBgZngQwBAgEwOwYDVR0fBDQwMjAwoC6gLIYqaHR0
cDovL2NybC5jb21vZG9jYS5jb20vUG9zaXRpdmVTU0xDQTIuY3JsMGwGCCsGAQUF
BwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5jb21vZG9jYS5jb20vUG9z
aXRpdmVTU0xDQTIuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5jb21vZG9j
YS5jb20wHwYDVR0RBBgwFoIKKi5ld2VrYS5ubIIIZXdla2EubmwwDQYJKoZIhvcN
AQEFBQADggEBAFMauxEIDkLFLMpCpuxRJjFB0Xmufdejx+eTu6ry6sbXIGc/ZGdq
U0zpscSUS1PExQYh7q0l9AvmE7UIG1tOjpPKvK4My7ecNZMMaGpX7CVb0W74Ol3A
UFhuMj4tCHizLi9XBa/j0wbJxqmsuV5U9Dz4YA2Y+EIHFy/ylgqm07rnWmSId7qL
IN7XyfNmieZfqYfvq0VHMQMqBSjjTPibouMYgCWmQFEl+RMSaok6rxedO59Z0u8t
6WRcx8YNwGjGZ9F4FAdElnMHO7i24nKQBjoNzMeCGcoCagwaFZ1w6BAoTFxOBMOl
9yG+e8amicf5Iy4Rsxmm+aOcNoLsd7ej2kc=
-----END CERTIFICATE-----
subject=/OU=Domain Control Validated/OU=PositiveSSL Wildcard/CN=*.eweka.nl
issuer=/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=PositiveSSL CA 2
---
No client certificate CA names sent
Server Temp Key: DH, 2048 bits
---
SSL handshake has read 4590 bytes and written 500 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES128-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : SSLv3
Cipher : DHE-RSA-AES128-SHA
Session-ID: F2E01C56D14B2F04E0676346623DE35C68243047ED909F95049FA
Session-ID-ctx:
Master-Key: 913751F76533AB12FB82AEC23C64D2EE324716014E153FB1EF3BED5D324F94EFACDA6505ADFCD129C4E
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1435324501
Timeout : 7200 (sec)
Verify return code: 19 (self signed certificate in certificate chain)
---
200 Welcome to Eweka (fx11.am4)

self signed .... mja, best wel jammer ja. en software controleert het kennelijk ook niet. zo te zien mag er aan beide kanten wel iets worden gefixed.

[CyBeR]

Fish schreef op vrijdag 26 juni 2015 @ 15:18:
[...]


[...]


self signed .... mja, best wel jammer ja. en software controleert het kennelijk ook niet. zo te zien mag er aan beide kanten wel iets worden gefixed.

Dat certificaat is niet self-signed.

[Fish]

wat is dit dan ?
Verify return code: 19 (self signed certificate in certificate chain)

ik zie wel een pad naar boven, maar kan daar niets iets mis zijn ?

[ Voor 28% gewijzigd door Fish op 26-06-2015 15:23 ]

[CyBeR]

Fish schreef op vrijdag 26 juni 2015 @ 15:22:
wat is dit dan ?
Verify return code: 19 (self signed certificate in certificate chain)

ik zie wel een pad naar boven, maar kan daar niets iets mis zijn ?

D'r zit altijd een self-signed certificate in de chain. De root certs zijn namelijk self-signed.

[Fish]

Ok beetje onzin melding dan ..

ik zie mijn mijn pop server idd ook staan .... en die heeft echt wel geldig certifikaat

[ Voor 58% gewijzigd door Fish op 26-06-2015 15:31 ]

[Resilldoux]

Fish schreef op vrijdag 26 juni 2015 @ 15:30:
Ok beetje onzin melding dan ..

ik zie mijn mijn pop server idd ook staan .... en die heeft echt wel geldig certifikaat

Het is niet onzin hoor, zoals CyBeR terecht aangeeft zijn root CA's inderdaad self-signed, maar omdat ze in de trust store zitten zijn ze gewoon vertrouwd. OpenSSL kan kennelijk niet zomaar zonder expliciet op te geven bij een dergelijke trust store vermoed ik?

offtopic:
Daarbij is er ook niet echt goede transparantie in welke CA's nu wel of niet als 'trusted' worden beschouwd. Iedereen gaat er in goed vertrouwen vanuit dat trusted CA's gewoon goed te vertrouwen zijn (kennen we DigiNotar nog?). Daarom hoop ik dat DANE een goed alternatief kan bieden voor de geldwolven die trusted CA's aanbieden en voor veel te dure prijzen een groen slotje mogelijk maken in de web browser.

[ Voor 30% gewijzigd door Resilldoux op 26-06-2015 15:54 ]

[Fish]

Lijkt er op dat het de clients zijn dan. (maar ja ik heb nog niet bewust met een self signed server op nntp verbonden) dus ook nooit zien failen.

Filezilla is wel zo dom. laat wel het certifikaat zien maar controleert niets, zoeits van: vertrouwen ? ja of nee. beetje ruk implementatie als je het vraagt. maar ik ben wel gewend aan filezilla
winscp weet ik niet, maar dat staat er ook op

offtopic:
en dan krijgen we we weer de discussie: wie controleert de mensen die de trusted lijst onderhouden etc etc

[ Voor 13% gewijzigd door Fish op 26-06-2015 17:21 ]

[Eagle Creek]

Een root-certificaat kan natuurlijk wel cross signed zijn maar in veel gevallen is hij self signed door de root. Zo werkt het systeem nu eenmaal.

Welke CA's je wel of niet kunt vertrouwen blijft een discussiepunt. Jij kunt als gebruiker of bedrijf dit zelf bepalen of vertrouwen op andere bedrijven die dit voor jou doen. En met andere bedrijven doel ik op Microsoft, Apple, Adobe, Mozilla, etc.

[Anoniem: 207968]

Als je encryptie belangrijk vind moet je naar Giganews kijken.
Behoorlijk prijzig ook.
https://www.ssllabs.com/s...=news-europe.giganews.com
Wat het allemaal is weet ik ook niet precies maar ze bieden extra's aan bij je abonnement, een VPN dienst;
http://nl.giganews.com/vyprvpn/
En nog een soort VPN dienst; beiden softwarematig;
http://nl.giganews.com/accelerator.html

Hier staat wat er verder mogelijk is, tegen een hoge prijs weliswaar.

[ Voor 15% gewijzigd door Anoniem: 207968 op 26-06-2015 20:34 ]

[Fish]

eweka heeft ook vpn inbegrepen bij sommige of misschiein wel alle abbo's

Get a Free VPN Account
IPVanish VPN
You can get free VPN access with Eweka.

[Resilldoux]

Dat sommige providers ook goede encryptie ondersteunen klopt, maar het gaat mij erom dat ze uitgerekend allemaal onveilige encryptie ook blijven ondersteunen. Kennelijk vinden ze een paar extra centen per maand belangrijker dan de onveilige encryptie uit te zetten en de 'ontwetende klant' daarmee zich tegen zichzelf te beschermen.

Als er iets gevaarlijk is, dan is het wel vertrouwen hebben in een veilig systeem (in dit geval verouderde protocollen en versleutelingen) dat helemaal niet veilig meer is. Even heel dramatisch, maar dat koste Maria I van Schotland haar leven toentertijd. :-)

[CAPSLOCK2000]

De meeste usenetproviders zijn resellers van een paar grote providers. Die resellers hebben niet eens hun eigen servers maar gebruiken die van hun provider. Dat zou een deel van verklaring kunnen zijn. Verder zijn het vaak maar hele kleine bedrijfjes met nauwelijks personeel en weinig omzet. Die proberen zo min mogelijk te investeren en zijn bang voor iedere verandering.

Ik geloof niet in het argument dat goede encryptie te duur is. CPU is geen bottleneck voor usenet. Daarbij hebben moderne CPU's hardwaresupport voor encryptie waardoor ze dit enorme efficient kunnen doen. Als CPU wel een bottleneck was dan zouden ze helemaal geen encryptie gebruiken.

[Resilldoux]

Na enige tijd heeft Eweka vandaag ook eindelijk gereageerd:

Hello Guido,

Thank you for your feedback, We are well aware of the status of our SSL encryption of the Usenet Service. And the reason of the supported security mechanisms not being top grade is indeed compatibility with older clients. Even though I agree that a higher level of security would be preferable, we are afraid it might not weigh up against the issues this might cause among our userbase.

About your comments regarding the Eweka webserver: We have immediately taken measures to increase the security. With flaws and weaknesses being found in (open)SSL quite regularly nowadays, staying on top of things is important. However, it seems we've been lagging behind in this regard. Today I have upgraded our webservers, only allowed TLSv1.2 (no older protocols) and disabled the RC4 cipher. You can verify yourself: https://www.ssllabs.com/ssltest/analyze.html?d=eweka.nl

I'm gonna bring up a discussion internally about the SSL encryption used on our newsservers. We may have to reevaluate the situation and make changes after all. Thank you again for brining the issues to our attention.

Kind regards,
Bart van Brakel
Eweka Support

Ik keur het feit af dat geld tot nog toe hoger opweegt dan veiligheid, maar dit is mijn inziens al een veel betere reactie dan Hitnews eerder. Hitnews bood mij extra dagen toegang aan tot hun diensten om, volgens mij van mijn gezeur af te zijn. Ik heb hen een reactie terug gestuurd dat ik eerder benieuwd ben naar hun reactie hoe zij tegenover dit probleem kijken, maar zelfs na een herinneringsmailtje heb ik nog niets van hen mogen horen...

Hopelijk gaat de interne discussie bij Eweka tot verbeteringen leiden. Ik heb ze nu net een reactie terug gestuurd dat ik blij ben dat er wat mee gedaan wordt en ze ook geattendeerd op de mysterieuze OpenSSL beveiligingslek dat morgen bekend gemaakt zal worden: nieuws: Enkele OpenSSL-versies getroffen door ernstig lek - update

[Fish]

Als het gaat om compatability zouden ze natuurlijk "gewoon" een 2e ssl server op kunnen met upto date encryptie.

[DJVG]

Ik kan hier wel enige inside informatie over geven.

Compatibiliteit is een echte (grote) issue, ontzettend veel mensen gebruiken oude clients en de support druk die ontstaat als je bepaalde ciphers uitzet wordt je niet vrolijk van.

Daarbij komt dat CPU gebruik op de zogenaamde frontends/readers absoluut meespeelt. AES-NI ondersteuning in de CPU helpt zeer veel, in de tijd dat dat niet aanwezig was had je serieus veel readers nodig of zelfs aparte SSL readers zoals veel Usenet providers gehad hebben. Tegenwoordig is dat probleem minder maar alsnog zijn er frontends die 2Gbit/s (of meer, 10Gbit/s) staan te rammen waarvan steeds meer SSL is. SSL is en blijft performance impacting, dit is onder andere de reden dat er zwakkere encryptie wordt gebruikt.

Dat het impacting is niet zozeer de server side, maar vooral client side. Mensen die hun goedkope NAS met SSL gebruiken en vervolgens klagen dat ze hun 100Mbit/s niet kunnen voltrekken (of oudere PC's). Daarbij ontvangt de betreffende Usenet dienst meteen een mail dat de snelheid niet gehaald wordt etc....

Daarbij moet je jezelf de vraag stellen of sterke beveilging echt belangrijk is, een Usenet provider is tenslotte geen bank...

Edit:
Het gebruik van een self-signed certificaat is natuurlijk sowieso nooit best practice en ik vermoed eerder dat dat komt door gebrek aan kennis of gewoon niet caren.

[ Voor 6% gewijzigd door DJVG op 08-07-2015 19:57 ]

[Resilldoux]

Bedankt voor je reactie DJVG! De toenemende support druk kan ik mij wel voorstellen, het overgrote deel aan gebruikers is vaak gauw niet zo technisch en zal vaak (te) gauw klagen over een performance drop m.b.t. een probleem dat zij (helaas) aan zichzelf te danken hebben.

Ik ken ook mensen in mijn directe omgeving die graag hobby'en in de IT en houtje-touwtje NAS-oplossingen draaien voor o.a. downloaden via nieuwsgroepen. Echter, veel providers bieden op hun website verouderde handleidingen en FAQs, als ze die überhaupt al aanbieden. Ik denk daarom dat providers veel kunnen verbeteren door niet alleen hun beveiligingen te verbeteren, maar daar ook hun klanten hiervan bewust te maken.

Up-to-date handleidingen, FAQs en wellicht discussie fora's kunnen hierbij helpen, ook om de klant tegen zichzelf te beschermen. En als het de klant echt niets interesseert of desondanks toch gebruik wil maken van verouderde news grabbers, dan kunnen ze altijd nog gebruik maken van poort 119, daar bieden providers dit kanaal immers ook voor.

Wat mij betreft moeten beveiligde kanalen altijd top notch zijn. Dit klinkt contra-intuïtief, maar geschiedenis leert ons dat slechte beveiliging vaak gevaarlijker is dan geen beveiliging.

[DJVG]

Resilldoux schreef op woensdag 08 juli 2015 @ 20:35:
Bedankt voor je reactie DJVG! De toenemende support druk kan ik mij wel voorstellen, het overgrote deel aan gebruikers is vaak gauw niet zo technisch en zal vaak (te) gauw klagen over een performance drop m.b.t. een probleem dat zij (helaas) aan zichzelf te danken hebben.
[knipperdeknip]

Ik ben het meer dan eens met je dat SSL perfect moet zijn, als je het dan doet, doe het goed. Helaas is de werkelijkheid anders. Ik ben bekend met de Usenet support van een bekende tent(en) en je wilt niet weten hoeveel procent van de klanten enkel spotnet gebruiken en daar al de grootste moeite mee hebben.

Daarbij is spotnet en clones verre van perfect en zorgt tegelijkertijd ook nog eens voor dat er server-side smerige hacks nodig zijn om het werkend te houden (vooral in het spotnet post gedeelte).

Nu gaat het in dit topic vooral over SSL en ik ben het met je eens dat de PC hardware tegenwoordig steeds sneller en beter wordt en dit dus geen probleem hoeft te zijn.

Daarbij wil ik nog wel vermelden dat de steeds snellere internet verbindingen een uitdaging blijven, met de juiste client configuratie / opstelling kan je snelheden van 500Mbit/s of zelf 1Gbit/s zonder problemen behalen (mensen willen graag dat hun 500Mbit/s wifi verbinding de 62MByte/s aantikt op hun 10 jaar oude SATA 1 maxtor schijf). Zo kan je die 500Mbit/s prima behalen met 5 verbindingen, mits je ISP goede verbindingen heeft en je eigen netwerk van goede hardware voorzien is (die 20 euro sweex router van de meeste redt het gewoon niet). Maar dit is misschien meer voor in een ander topic.

Nogmaals, SSL moet veilig zijn maar ik snap de houding van Usenet tenten ook, support is nou eenmaal duur en goede support mensen vooral die zelf kennis van zaken hebben

[Resilldoux]

Het is dan echt jammer dat er zoveel gebruikers zijn die nog verouderde en stagnerende news grabbers gebruiken. Ik snap daarmee goed dat veel providers veel belang hebben bij het ondersteunen van een breed scala aan gebruikers die die onveilige grabbers nog gebruiken.

Over wat voor hacks heb je het trouwens, als je daar wat over kunt vertellen??

Echter, het zou zo veel mooier zijn als de providers zich verantwoordelijker zouden opstellen als het gaat om beveiliging. Up-to-date informatie aanbieden op je website is wat mij betreft de eerste stap (handleidingen, FAQs, fora, etc.). Maar die informatie is vaak outdated, of zelfs helemaal niet waar. YabNews promoot SSL bijvoorbeeld als 'anoniem' op hun voorpagina: http://yabnews.nl/. SSL is niet anoniem, zelfs niet pseudoniem; het biedt slechts vertrouwelijkheid zodat anderen de informatie niet kunnen onderscheppen (mits fatsoenlijk geïmplementeerd uiteraard, hetgeen bij geen enkele provider tot nog toe aan de hand is). Anonimiteit is met SSL niet te waarborgen, daar is het immers ook helemaal niet voor ontworpen.

Juist, ja wat betreft de toenemende snelheid heb je helemaal gelijk. Dit zijn nou echt puntjes die op een FAQ pagina kunnen worden verwerkt waar klanten van kunnen leren. Goed, nog beter zou zijn wanneer ISP's betere apparatuur zou aanbieden, maar dat is ook weer beetje offtopic.

Support is duur, dat is waar en kennelijk verdient het niet goed genoeg. Daarmee wordt het een utilistische afweging waar geld belangrijker is dan het waarborgen van beveiliging en dat maakt mij vaak zwaarmoedig.

[Fish]

Over wat voor hacks heb je het trouwens, als je daar wat over kunt vertellen??

Ik go zo dat het (o.a.) gaat over bijv herindexatie. dat gaat spotnet over de pis (been there). Dan krijg je natuurlijk de hele spotnet scene over je heen op de helpdesk tewijl je alleen even de db moet wegpleueren
e.g. https://www.eweka.nl/nl/numbering_faq/

[DJVG]

Zonder al te veel in detail te gaan heeft het vooral met de headers en de ondersteunde commando's te maken binnen spotnet.
Waarbij het message-id bij elke provider hetzelfde (door de user genereert of posting kant van nieuwsserver) is is dat van een artikel nummer niet zo (daarom moet je je spotnet database altijd opnieuw aanmaken bij switchen van Usenet provider).
Headers zijn een lastig geval in Usenet land, iedereen die iets met Usenet aan de achterkant te maken heeft (gehad) weet dat headers een ramp zijn.

Belangrijk is om te weten dat we het dan niet over het HEAD commando hebben maar als je bijv een xover doet. Met dit commando haal je een (range) van headers op. Je moet je voorstellen dat de headers ook gewoon tekst zijn.

Bij een bekende Usenet providers bevat de group free.pt (de groep die spotnet gebruikt voor zijn overzicht) 1427398 artikelen (op dit moment, is zo al weer hoger natuurlijk).
Als jij dus je spotnet database aanmaakt moet hij 1427398 headers opvragen en vervolgens van die headers de artikelen weer ophalen. Nu gebruikt spotnet hier meerdere commando's voor, bijvoorbeeld XOVER, maar ook XHDR kan worden gebruikt om enkel het message-id op te vragen, zo kan je bijvoorbeeld de eerste 5 message-id's opvragen van free.pt:

code:

xhdr Message-ID 1937251-1937256
221 Message-ID fields follow
1937251 <[e-mail]>
1937252 <[e-mail]>
1937253 <[e-mail]>
1937254 <[e-mail]>
1937255 <[e-mail]>
1937256 <[e-mail]>
.

Nu staan de bovenstaande nummers netjes in volgorde, het gaat goed verkeerd als die nummers niet meer in volgorde staan, zeker als er backlog ontstaat omdat er iets kapot is, dat vind spotnet niet leuk en gaan mensen klagen dat de data niet in volgorde staat in hun spotnet.

Omdat je als Usenet provider niet weet wat je mist kan je het ook niet op volgorde zetten of ruimte reserveren. Ook is het zo dat het afhankelijk is van hoe je nummert, early of late numbering. Dit is vooral belangrijk voor je spamfiltering. Gebruik je early numbering dan heb je gegarandeerd gabs in je nummers. Spotnet kan hier redelijk mee omgaan maar goed is het absoluut niet en mag volgens de RFC ook niet (als ik het goed onthouden heb, correct me if i'm wrong).

Headers zijn ontzettend zwaar om op te slaan van de backend te halen en er zijn veel methode gebruikt en getest (niet publiek) om dit snel te houden (de info die nodig is voor xovers / xhdr etc..).

Een belangrijke "hack" die nodig was is de size van de headers, spotnet propt zoveel in een header dat dat een probleem was in het begin, ook in de uitwisseling tussen Usenet providers was dit een probleem omdat er een (afgesproken) limiet was aan de header size.

Helaas kaap ik dit topic helemaal, maar stel gerust vragen, denk dat ik aardig wat kan beantwoorden zonder vertrouwelijke info te lekken.

Om het toch nog een beetje ontopic te houden:
SSL is heel belangrijk, als is het maar voor de authenticatie. Al zal bij de meeste enkel de verbinding naar de frontends beveiligd zijn, de verbindingen daarachter naar de verschillende servers is dat natuurlijk niet.

[devil-strike]

Dan vraag ik me af hoe het met newsleecher servers zit.

OpenSSL> s_client -connect eu.newsleecher.com:563
Loading 'screen' into random state - done
CONNECTED(000001EC)
depth=3 C = US, O = "The Go Daddy Group, Inc.", OU = Go Daddy Class 2 Certification Authority
verify error:num=19:self signed certificate in certificate chain
---
Certificate chain
0 s:/OU=Domain Control Validated/CN=*.sslusenet.com
i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
1 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
i:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2
2 s:/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./CN=Go Daddy Root Certificate Authority - G2
i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
3 s:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
i:/C=US/O=The Go Daddy Group, Inc./OU=Go Daddy Class 2 Certification Authority
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIFKTCCBBGgAwIBAgIHJ3zTH52K7DANBgkqhkiG9w0BAQsFADCBtDELMAkGA1UE
BhMCVVMxEDAOBgNVBAgTB0FyaXpvbmExEzARBgNVBAcTClNjb3R0c2RhbGUxGjAY
BgNVBAoTEUdvRGFkZHkuY29tLCBJbmMuMS0wKwYDVQQLEyRodHRwOi8vY2VydHMu
Z29kYWRkeS5jb20vcmVwb3NpdG9yeS8xMzAxBgNVBAMTKkdvIERhZGR5IFNlY3Vy
ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkgLSBHMjAeFw0xNDA0MTUyMTU0MDRaFw0x
ODA4MTIxNjI0MzlaMD0xITAfBgNVBAsTGERvbWFpbiBDb250cm9sIFZhbGlkYXRl
ZDEYMBYGA1UEAwwPKi5zc2x1c2VuZXQuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOC
AQ8AMIIBCgKCAQEA2OKSnW0vJqxVmdonzIIQhrZdSBRVYL1ewDOwezd7+iWOhp0l
vBx9LrtMpFaFXLipqboWIBK52au43Se1j+gpowRB5mWmt6FR0qIXxQ+tVWm1EkEA
k86ByXaezZYoRMmSZSRPD0sbGHUaUl/HD2SghHDI/PLF/0Kkte0PJfn6P5cpqvK6
LrRS+brJDbC0SQ7cyEj8q/hBsDkulGlE5Y6Q4Y+OvC3ZD/7XipD12ibqh6GDLo5p
qghrbEpX/3ID5YeAtLhbVDx8UGVD3LSuyLRnSO80AMXN8vLuxvC7Lo1j+XH2Wy8j
Vx+grBOPvq6PrT7/EN414LsA0oy6MmMdCItBPQIDAQABo4IBtDCCAbAwDwYDVR0T
AQH/BAUwAwEBADAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwDgYDVR0P
AQH/BAQDAgWgMDYGA1UdHwQvMC0wK6ApoCeGJWh0dHA6Ly9jcmwuZ29kYWRkeS5j
b20vZ2RpZzJzMS00My5jcmwwUwYDVR0gBEwwSjBIBgtghkgBhv1tAQcXATA5MDcG
CCsGAQUFBwIBFitodHRwOi8vY2VydGlmaWNhdGVzLmdvZGFkZHkuY29tL3JlcG9z
aXRvcnkvMHYGCCsGAQUFBwEBBGowaDAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Au
Z29kYWRkeS5jb20vMEAGCCsGAQUFBzAChjRodHRwOi8vY2VydGlmaWNhdGVzLmdv
ZGFkZHkuY29tL3JlcG9zaXRvcnkvZ2RpZzIuY3J0MB8GA1UdIwQYMBaAFEDCvSeO
zDSDMKIz1/tss/C0LIDOMCkGA1UdEQQiMCCCDyouc3NsdXNlbmV0LmNvbYINc3Ns
dXNlbmV0LmNvbTAdBgNVHQ4EFgQUT+xg72+c80aJaO8jkWfXYpNSlOUwDQYJKoZI
hvcNAQELBQADggEBAFGuN/EwmaaI2iWkTpxHyVOvyNNfo9w+2QV4NVMCe1imGEFz
Pg2u+bnaRDDJb85VE6PS3StlELToGN+KvsDm86X5Kcp7q1CdeXLPvzrCMJgOkbfa
MNPepLkxx8m9rP6t+ATXO3baxMTnSezJa8n7XDcPxJrLrXFo5KYjonun/0EnqIkI
6U+3mQkfNMpX6cG9VfJi8Wwcgp0Bed/fsvYKlS3Xb6QVVzbsFrAavdB3D+o84m1H
o2GknY73JPCM9FXrzEI+4ca4VS44No4sWREmEZSKG6k4AgrA2pQl2pefxqym37v/
3jIiYSKvjv0RCtBgeeUZKlRHi8rAV58hqiLzf6E=
-----END CERTIFICATE-----
subject=/OU=Domain Control Validated/CN=*.sslusenet.com
issuer=/C=US/ST=Arizona/L=Scottsdale/O=GoDaddy.com, Inc./OU=http://certs.godaddy.com/repository//CN=Go Daddy Secure Certificate Authority - G2
---
No client certificate CA names sent
Peer signing digest: SHA512
Server Temp Key: DH, 2048 bits
---
SSL handshake has read 5729 bytes and written 659 bytes
---
New, TLSv1/SSLv3, Cipher is DHE-RSA-AES128-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
Cipher : DHE-RSA-AES128-SHA
Session-ID: EAB5C04D5EF00906BB47159EA6B7B250C8B3DE3AD8C901E2CB9B32783B6D523E
Session-ID-ctx:
Master-Key: D1AAB4CBF46D2E10A811C181BC957E77CE3BAD9CA456E92366BD64792365CBBDD14BE00B7A43EEE85E07D867C307BD9D
Key-Arg : None
PSK identity: None
PSK identity hint: None
SRP username: None
Start Time: 1436425833
Timeout : 300 (sec)
Verify return code: 19 (self signed certificate in certificate chain)


Na mijn idee is dit gewoon prima?

[DJVG]

Het SSL cert zelf is wel in orde, maar de CN klopt niet met het domein (*.sslusenet.com zie ik wel vaker, hint hint).

Wel zie ik dat ze nog steeds SSLv2, SSLv3 en RC4 ondersteunen en mogelijk vatbaar is voor Poodle.

Overigens is dat niet zo vreemd want zo te zien draait dit bij een grote tent die zijn config's redelijk gelijk trekt

[devil-strike]

Ah ok bedankt voor de info niet dat ik er veel van snap heheheh.

Maar goed newsleecher maakt dus ook gebruik van 1 van de 3? grote usenet farms.

[DJVG]

Enige wat ik kan zeggen is kijk eens naar het IP en voer die in bij de bekende IP tools op het www.

[Resilldoux]

DJVG schreef op donderdag 09 juli 2015 @ 09:43:
Enige wat ik kan zeggen is kijk eens naar het IP en voer die in bij de bekende IP tools op het www.

Interessant, dat wist ik niet. Ik heb het volgende snel in kaart kunnen brengen:

code:

+-----------------+---------------------------+
| Provider        | WHOIS-gegevens            |
+-----------------+---------------------------+
| Eweka           | Eweka                     |
+-----------------+                           +
| NewsLeecher     |                           |
+-----------------+---------------------------+
| XLned           | Base IP B.V.              |
+-----------------+                           +
| VoordeligUsenet |                           |
+-----------------+                           +
| ExtremeUsenet   |                           |
+-----------------+                           +
| Usenet.pro      |                           |
+-----------------+---------------------------+
| YabNews         | XS News B.V.              |
+-----------------+                           +
| UsenetBucket    |                           |
+-----------------+---------------------------+
| 123Usenet       | XL Internet Services B.V. |
+-----------------+---------------------------+
| NextGenNews     | Interactive 3D B.V.       |
+-----------------+---------------------------+
| Newshosting     | Newshosting               |
+-----------------+                           +
| UsenetServer    |                           |
+-----------------+---------------------------+

Bovenstaande gegevens achterhaald met:

code:

$ dig +short <newsserver adres>
123.123.123.123
$ whois 123.123.123.123
<WHOIS gegevens van betreffende IP-adressen>

Weer ontopic.

De volgende mails heb ik heen en weer verstuurd naar YabNews aangaande hun SSL verbinding (full disclosure): http://pastebin.com/1pdGD0vm

Hierna heb ik niets meer van ze gehoord

[ Voor 4% gewijzigd door Resilldoux op 11-07-2015 15:38 ]

[DJVG]

Resilldoux schreef op zaterdag 11 juli 2015 @ 15:25:
[...]


Interessant, dat wist ik niet. Ik heb het volgende snel in kaart kunnen brengen:

Mooi werk! Nog 1 tipje, zoek nu eens in bijv. de database van KvK op welke addressen dit soort bedrijven bijvoorbeeld zitten.

[Resilldoux]

DJVG schreef op zaterdag 11 juli 2015 @ 16:45:
[...]


Mooi werk! Nog 1 tipje, zoek nu eens in bijv. de database van KvK op welke addressen dit soort bedrijven bijvoorbeeld zitten.

Wauw, dit is wel erg grappig ja:

code:

+-----------------+-----------------------------------------+-------------------+----------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Provider        | WHOIS-gegevens                          | Adres volgens KvK | Betreft              | Links                                                                                                                                                                                   |
+-----------------+-----------------------------------------+-------------------+----------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Eweka           | Base IP B.V.                            | Staten Bolwerk 1  | Mooi stukje landgoed | https://www.google.nl/maps/place/Staten+Bolwerk+1,+2011+MK+Haarlem/@52.3885155,4.6358285,17z/data=!3m1!1e3!4m2!3m1!1s0x47c5ef0d381fb4dd:0x69e4853213462f4c                              |
| Extreme Usenet  | Eweka                                   | 12011 MK Haarlem  | dat kennelijk als    | https://www.openstreetmap.org/node/2714804788                                                                                                                                           |
| Usenet.pro      |                                         |                   | bedrijfspand te huur | https://www.ksbedrijfsmakelaars.nl/aanbod/176/staten-bolwerk-1-|-all---in/                                                                                                              |
| VoordeligUsenet |                                         |                   | staat in hartje      |                                                                                                                                                                                         |
| XLned           |                                         |                   | Haarlem?             |                                                                                                                                                                                         |
+-----------------+-----------------------------------------+-------------------+----------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| NextGenNews     | Interactive 3D B.V.                     | Meent 93B         | Winkelstraat         | https://www.google.nl/maps/place/Meent+93B,+3011+JG+Rotterdam/@51.9223626,4.482928,18z/data=!3m1!1e3!4m2!3m1!1s0x47c433596d643019:0x774103cfd8b735b8                                    |
|                 |                                         | 3011 JG Rotterdam | appartementje        | https://www.openstreetmap.org/way/7525968                                                                                                                                               |
|                 |                                         |                   | in hartje Rotterdam? |                                                                                                                                                                                         |
+-----------------+-----------------------------------------+-------------------+----------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| UsenetBucket    | XS News B.V.                            | New Yorkstraat 9  | Op bedrijventerein;  | https://www.google.nl/maps/place/New+Yorkstraat+9,+Airport+Businesspark+Lijnden,+1175+RD+Lijnden/@52.3483738,4.759837,17z/data=!3m1!1e3!4m2!3m1!1s0x47c5e15526e11a7f:0x1500b9b9fa81a6e3 |
| YabNews         |                                         | 91175 RD Lijnden  | seems legit          | https://www.openstreetmap.org/node/2744620290                                                                                                                                           |
+-----------------+-----------------------------------------+-------------------+----------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| 123Usenet       | XL Internet Services B.V. (nu CloudVPS) | Delftsestraat 5   | Bedrijfspand;        | https://www.google.nl/maps/place/Delftsestraat+5,+3013+AB+Rotterdam/@51.9252267,4.4765425,17z/data=!3m1!1e3!4m2!3m1!1s0x47c434a7c2e44b7b:0x398b32c94a555fa0                             |
|                 |                                         | 3013 AB Rotterdam | seems legit          | https://www.openstreetmap.org/way/7525634                                                                                                                                               |
+-----------------+-----------------------------------------+-------------------+----------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+

Die bovenste heeft een groot stuk marktaandeel schat ik zo in, maar wel merkwaardig dat het op adres van dit vermoedelijk lege pand staat. Ziet er wel mooi uit van binnen, jammer dat ik er niet genoeg geld voor kan ophoesten.