MagicalTux in Japan

Geekness brought me to Japan!

Posts Tagged OVH

OVH: “The Wikileaks case”

Dec 4

Posted by MagicalTux in Geek Attitude | 2 Comments

Today, Octave (OVH’s founder & CTO) posted an email about Wikileaks…

Original in French:

Bonjour,
Comme vous savez certainement, le site wikileaks est hébergé sur nos infrastructures depuis hier très tôt le matin. Il s’agit d’un client qui a commandé un serveur dédié, avec les blocs RIPE et de protections contre les attaques. Sa facture payée par CB s’élève à moins de 150euro. Et donc il héberge le site wikileaks. Juridiquement parlant Ovh n’est pas l’hébergeur de ce site. Ovh est, juste, le prestataire technique de la solution technique que le client a commandé.
Bref, l’histoire est banale et quotidienne. Le système est totalement automatique et fonctionne 24 heures sur 24. Nous avons découvert comme vous tous que ce site est chez nous hier … dans la presse.
Ovh n’est ni pour ni contre ce site. La question hors sujet pour nous. Ovh est une entreprise qui fournit les infrastructures, le fameux cloud computing disponible en quelques heures …, et notre rôle est d’assurer cette prestation technique. C’est tout. On n’a pas demandé d’héberger ce site ou ne pas l’héberger. Maintenant qu’il est chez nous on assure le contrat. C’est notre boulot. Il est fonctionnel.
Compte tenu de dernières déclarations politiques, et de pressions qui commencent réellement à se sentir, même ici à Roubaix Valley, nous avons décidé de saisir le juge en référé afin qu’il se prononce sur la légalité ou pas de ce site sur le territoire français. Ce n’est pas au monde politique ni à Ovh de demander ou de décider la fermeture ou pas d’un site mais à la justice. C’est comme que ça doit marcher dans un pays de droit.
Nous espérons que le juge donnera sa décision avant ce soir ou demain. Et Ovh appliquera la décision immédiatement.
Amicalement
Octave
Translated into english (in less than 5 minutes, then fixed with the help of mourn on IRC):
Good afternoon,
As you may already know, the wikileaks website is now hosted on our infrastructures since yesterday early in the morning. It’s a normal customer who only ordered a dedicated server, with a RIPE block and protections against attacks. His invoice paid by credit card was less than 150euro. And he is hosting wikileaks. Legally speaking, Ovh is not hosting this site. Ovh is, only, the technical provider of the technical solution ordered by the customer.
Well, the story is usual and happens everyday. The process is fully automated and is working 24 hours a day. We have discovered this with you yesterday… in the press.
Ovh is not for nor against this site. The question is irrelevent to us. Ovh is a company providing infrastructures, such as our famous cloud computing available in a few hours…, and our role is to handle this technical prestation. That’s all. We didn’t ask to host Wikileaks or not. Now that it is here we follow the contract. It’s our work. It’s working.
Following the latest political declarations, and policical pressure that really begins to be felt, even here at Roubaix Valley, we have decided to refer to a judge for summary judgment to have him state the legality of this site on the french territory. It is not up to the political world nor up to Ovh to decide to close a website or not, but up to the legal system. This is how it is supposed to work in a constitutional state where the government is constrained by the law.
We hope the judge will tell us his decision before tonight or tommorow. And Ovh will apply this decision immediatly.
Amically
Octave
The “pressure” mentionned in Octave’s email is already mentionned on Reuters.
Now, I have some doubts about OVH mentionning “wikileaks is just another customer”. As a matter of fact, when ordering a RIPE IP block with OVH, the country choice is limited to some european countries (wikileaks’ ip block is stating “Australia” as a country) and the admin-c/tech-c is always OTC2-RIPE (wikileaks got its own admin-c/tech-c with its own abuse email).
IP Whois:

% This is the RIPE Database query service.
% The objects are in RPSL format.
%
% The RIPE Database is subject to Terms and Conditions.
% See http://www.ripe.net/db/support/db-terms-conditions.pdf
% Note: This output has been filtered.
%       To receive output for a database update, use the "-B" flag.
% Information related to '213.251.145.96 - 213.251.145.111'
inetnum:        213.251.145.96 - 213.251.145.111
netname:        WIKILEAKS
descr:          wikileaks.org
country:        AU
admin-c:        WL805-RIPE
tech-c:         WL805-RIPE
status:         ASSIGNED PA
mnt-by:         OVH-MNT
source:         RIPE # Filtered
person:         Wiki leaks
address:        BOX 4080
address:        University of Melbourne Branch
address:        Victoria 3052
address:        Australia
phone:          +33974760185
nic-hdl:        WL805-RIPE
abuse-mailbox:  abusesp@gmail.com
mnt-by:         OVH-MNT
source:         RIPE # Filtered
% Information related to '213.251.128.0/18AS16276'
route:        213.251.128.0/18
descr:        OVH ISP
descr:        Paris, France
origin:       AS16276
mnt-by:       OVH-MNT
source:       RIPE # Filtered

Of course there is no way to tell for sure…

Tags: ,

Registrars and authcodes

Mar 11

Posted by MagicalTux in Geek Attitude | No Comments

Many registrars out there have found different ways to implement Verisign’s requirement of harder-to-guess authcodes for domains by asking to have at least one symbol character (non letter, non number) in the authcode.

This had different effect on different registrars. For example french registrar OVH have implemented it a bit too well, resulting in authcodes like “d*zuW.;2t/!>pHbU”, while others have decided that it wasn’t their problem, and just added a prefix to their authcodes. This is the case for example of GoDaddy, whose authcodes are limited in randomness. An authcode will look like: “S1-AF94C9510BA1C”. Yeah right, “S1-” followed by an uppercase hexadecimal string. I’m pretty sure Verisign wasn’t expecting this when they published the new requirement.

Anyway conditions to steal a domain are pretty much complex (you need to have it unlocked, need to know the authcode, and once transfer is started, the current registrant must not ask his registrar to cancel the transfer for 5 days, and even after the domain is transferred, there are ways to get it back – it’s just more expensive). Stealing a domain is a complex operation which will most likely be followed by legal repercussions.

Best thing to do is to check from times to times in a whois that your domain is really showing your name and address. If not, you might need to do something about it before it’s too late. You might want to consider transferring your domain to a company which cares about you ;) (we’ll even fight your old provider if troubles arise, they can refuse transfer only in some specified cases, as long as you are owner of your domain).

Tags: , , , , , ,

OVH, French registrar ignorant of ICANN policies

Dec 4

Posted by MagicalTux in Geek Attitude | No Comments

OVH is an ICANN-accredited French registrar which accepted the ICANN 2009 RAA (Registrar Accreditation Agreement).

Being a registrar implies understanding and applying a lot of rules, especially when dealing with domain names transfers.

For example domain name transfers policies defines how the losing registrar and winning registrar must act. Part 3 is especially interesting as it states reasons why a losing registrar can or cannot deny an outgoing transfer.

Allowed reasons to deny a transfer includes:

  1. Evidence of fraud
  2. UDRP action (Unified Domain-name Dispute Resolution Policy)
  3. Court order by a court of competent jurisdiction
  4. Dispute over the identity of the domain name owner
  5. No payment for previous registration period
  6. Express written objection to the transfer from the Transfer Contact (email, fax, paper document, etc)
  7. The domain is locked (only acceptable if registrar provides a mean to remove lock status)
  8. The domain is too young (must be at least 60 days old before transfer)
  9. Domain has been transferred in the last 60 days (or less, up to the registrar)

Any other reason is not acceptable, especially:

  • Non-payment for a pending or future registration period
  • No response from the Registered Name Holder or Administrative Contact
  • Domain is locked (unless is is possible to unlock it)
  • Domain time constraints (except those stated before)
  • General payment default for other services

Our friends at OVH decided to provide extra protection (aren’t they just trying to prevent customer from going elsewhere?) to domain owners, and add a transfer page to authorize outgoing transfers. When transferring from OVH to somewhere else, the contacts are required to accept the transfer on a specific page. Not accepting the transfer within 48 hours means the transfer won’t happen (at least that’s what the page itself says).

  • This is not allowed by ICANN. Even worse since this is explicitly forbidden.
  • This stupid page takes up to 20 seconds to appear, timings from the OVH network itself confirms it
  • It also contains a stupid CAPTCHA which in turn also takes up to 20 seconds to appear
  • For some TLDs (tested with .fr ccTLD) OVH does not apply this procedure, so why only for gTLD ? (tested with .com .net .org .info)

Of course, I first tried to contact the OVH support, by mail, phone and even writing to Octave (the OVH CEO).

Phone attempt was of course useless (“please contact support by mail, ok I’ll tell the administrator too”  but nothing has happened), mail support proven to be even more useless, and Octave didn’t reply.

Mail support timeline:

  • 2009-11-25 00:50:12: Support initial contact explaining outgoing confirmation page is slow
  • 2009-11-28 11:18:48: Support replies asking “which domain is concerned?”
  • 2009-11-28 11:54:53: Reply to support with list of all domains and explicitly says “All domains I am about to transfer from OVH”
  • 2009-11-30 11:06:01: Reply from support “your problem is related to the display time of the tranfer to OVH order page, if you want we can generate the order for you”

The last solution was to contact ICANN, which is now done. Let’s see how this problem will resolve, however I won’t fight with this transfer page unless I’m on a transfer that *must* happen. Let’s see how OVH will justify denying the transfer in the even no reply comes from the domain contacts…

Tags: , , , ,