EPP Server SSL_Read hang after greeting-CodePudding

I have strange problems in ssl_read/ssl_write function with EPP server After connected I read greeting message successfully.

    bytes = SSL_read(ssl, buf, sizeof(buf)); // get reply & decrypt 
    buf[bytes] = 0;
    ball = bytes;

    cc = getInt(buf);
    printf("header: %x\n",cc);
    printf("Received: \"%s\"\n",buf 4);

First 4 bytes are 00, 00, 09, EB and read 2539 bytes in greeting message. After that, all operations like hello or logins are hand when SSL_read();

xml= "<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"no\"?><eppxmlns=\"urn:ietf:params:xml:ns:epp-1.0\"><hello/></epp>";
char bb[1000] = {0};
makeChar(strlen(xml) 4, bb);
memcpy(bb 4, xml, strlen(xml) 4);
bytes = SSL_write(ssl,xml,strlen(xml) 4);

usleep(500000);   //sleep 0.5 sec
memset(buf, 0, 1024);
printf("read starting.\n");
bytes = SSL_read(ssl, buf, 1024);   //always hang here
buf[bytes]=0;
printf("%d : %s", bytes, buf);

I am confused. I read RFC documentations but I can not find answer.

in EPP documentation, they said "In order to verify the identity of the secure server you will need the ‘Verisign Class 3 Public Primary Certification Authority’ root certificate available free from www.verisign.com".

is it important?

CodePudding user response：

is it important?

Yes, as outlined in RFC 5734 "Extensible Provisioning Protocol (EPP) Transport over TCP", the whole security of an EPP exchange is bound to 3 properties:

access list based on IP address
TLS communication and verification of certificates (mutually, which is why you - as registrar aka client in EPP communication - have often to send in advance the certificate you will use ot the registry)
the EPP credentials used at <login> command.

Failure to properly secure the connection can mean:

you as registrar sending confidential information (your own EPP login, various details on domains you sponsor or not, including <authInfo> values, etc.) to a third party not being the registry
and in reverse, someone mimicking you in the eyes of the registry hence doing operations on which you will have to get the burden of, including financially for all domains bought, and legally.

But even in general for all cases of TLS handshake, if you want to be sure to be connected, as client, to the server you think you are, you need to verify its certificate.

Besides trivial things (dates, etc.), the certificate:

should at least be signed by an AC you trust (your choice who you trust)
and/or is a specific certificate with specific fingerprint/serial and other characteristics (but you will have to maintain that when the other party changes its certificate)
and/or matches DNS TLSA records

In short, if you are new to both EPP and TLS and C/C (as you state yourself in your other question about Verisign certificate), I hugely recommend you do not try to do all of this by yourself at a so low level (for example you should never manipulate XML as you do above, it shouldn't be a string. Again, there are libraries to properly parse and generate XML documents). You should use an EPP library that leverage most of the things for you. Your registry may provide an "SDK" that you can use, you should ask it.

PS: your read is probably hanging because you are not sending the payload in the correct fashion (again, something an EPP library will do for you). You need to send the length, as 4 bytes (which you need to compute after converting your string to bytes using the UTF-8 encoding), and then the payload itself. I am not sure this is what your code does. Also your reading part is wrong: you should first read 4 bytes from server, this will give you the length (but do note they can theoretically arrive not necessarily in a single packet so one "ssl read" might not give all 4 of them, you need a loop), after which you know the length of the payload you will get which allows you to set up proper buffers, if needed, as well as detecting properly when you received everything.