[ITNOG] EPP con NIC.it

Daniele Orlandi daniele@orlandi.com
Mar 2 Mar 2010 00:37:20 CET


Ho bisogno di sfogarmi :)

Sto implementando un'interfaccia tra il mio sistema di provisioning e il NIC 
via EPP.

Mi sembra di parlare con un muro di gomma di persone in write only che non è 
minimamente interessato a capire quello che scrivo ma piuttosto a difendere lo 
status quo come se fosse impossibile che esistano dei problemi dal loro lato.

Il NIC utilizza EPP over HTTPS che non è standard e questo dovrebbe già far 
riflettere su quanto sia solido questo status quo.

Tralasciamo pure il fatto che HTTPS ha un utile autenticazione a chiave 
pubblica e il protocollo usa registry_id + secret...

Tra i requisiti mi trovo che il sistema mi obbliga a cambiare il secret ogni 
180 giorni.

Faccio loro presente che chi si autentica non è un essere umano, non è un 
incaricato della gestione di dati personali, bensì un altro sistema e neanche 
nella più bacata interpretazione del codice della privacy i server si devono 
"cambiare la pssword".

La risposta in sintesi è: "È così"[1]

Va bene, tappiamoci il naso e andiamo avanti. Finisco la mia implementazione e 
parto coi test formali.

Prima di questo avevo individuato una potenziale ambiguità nel protocollo. 
Essendo HTTPS stateless e EPP stateful, con un bel cookie JSESSIONID si tiene 
traccia della sessione.
La sessione ha durata di 30 minuti, che a me pare un po' pochino, visto che le 
"risorse" che usa una sessione sono un filetto nel webserver o un record in un 
DB (per confronto, Verisign ha un timeout di 24 ore).

Quindi mi pongo il problema: "Come faccio a sapere se la mia sessione è ancora 
valida?"

Dico... provo a mandare un comando, se la sessione è scaduta mi arriverà un 
errore e da lì capirò.

Provo e l'errore che mi arriva è un "2002 Command use error" e lì inizio a 
storcere il naso. Non mi sembra un codice molto specifico e quindi chiedo al 
NIC se posso contare sul fatto che quel codice arriva se e solo se la sessione 
è scaduta/invalida.

Risposta: "Sì!"

Ottimo, allora procedo con i test formali.

Al primo messaggio che il loro server per i test non si aspetta cosa mi 
arriva? Un bel "2002 Command use error"! Mavaff.....

Va bene, tarocco un po' il client per proseguire con i test (ho 60 minuti di 
tempo per finirli eh!).

Vado avanti e c'è da dare un comando di modifica di un dominio.

Il mio client prende la versione attuale del dominio con un comando info, vede 
cosa è cambiato e manda la modifica dei soli attributi cambiati.

Procedo e sbam, il server non si aspetta l'info request.

Faccio presente che è così che funziona il client e che è un comportamento 
lecito quindi il server del test non si deve lamentare.

Risposta: "Eh, ma il nostro server ha una macchina a stati e processa solo i 
messaggi che si aspetta, deve modificare il client per mandare solo il 
messaggio di modifica"

Intanto dire "è una macchina a stati" suona tanto come una supercazzola, 
perché la macchina a stati non impedisce di rimanere nello stato corrente per 
un set di eventi (tutte le query per esempio).

Il problema sostanziale è che se io tarocco il mio client per fargli passare 
il test quello che sto testando non è più il mio client ma un'altra cosa e il 
test formale va a farsi benedire.

Totalmente surreale anche perché nei test di compliance di solito funziona al 
contrario :)

Risposta: "Il nostro sistema è così[1]"

Risposta2: "Sul server di test la sessione dura 60 minuti quindi è impossibile 
che scada". Devo commentare?

[UPDATE] Pare che qualcuno si sia accorto dell'ambiguità del protocollo e 
abbia aggiunto un reason code esplicito per la sessione invalida. Peccato che 
il fix sia solo sul server di accreditamento e non ci sia né sul server di 
test, né su quello in produzione. Ma in un paio di settimane dovrebbe arrivare 
l'aggiornamento anche lì... sperém.

Mi chiedo se sono io l'unico stronzo che si preoccupa di queste cose, se mi 
sta crescendo dentro una paranoia eccessiva o se dovrei fare le cose alla 
"mentula canis" come altri... bah :)

Ciao,

[1] Trad.: "se non le va bene si attacchi (non al server)"

-- 
  Daniele "Vihai" Orlandi
  Bieco Illuminista #184213


More information about the itnog mailing list