I cant get libcurl perform to work properly in a especific url - libcurl

Im am working with libcurl on Visual Studio 2017 to get an request from a google url but the program crashes without call the exception that is trapped. I´ve tested with 2 others urls and it worked fine. The google url is:
"https://maps.googleapis.com/maps/api/elevation/json?locations=-23.64737184441803,-46.624&key=AIza...."
When I execute perform the code breaks without been catch by the exception:
the code is:
std::stringstream get_response(std::string_view url)
{
std::stringstream str;
curl::curl_ios<std::stringstream> writer(str);
curl::curl_easy easy(writer);
easy.add<CURLOPT_URL>(url.data());
easy.add<CURLOPT_FOLLOWLOCATION>(1L);
easy.add<CURLOPT_VERBOSE>(1L);
try
{
easy.perform();
}
catch (curl::curl_easy_exception error)
{
auto errors = error.get_traceback();
error.print_traceback();
}
return str;
}
I´ve looked at several sites without success.
Any help will be appreciated

I got a little more information from the log:
...
schannel: SSL/TLS connection with maps.googleapis.com port 443 (step 2/3)
schannel: encrypted data got 778
schannel: encrypted data buffer: offset 3542 length 4096
schannel: next InitializeSecurityContext failed: Unknown error (0x80092013) -The revocation function was unable to check revocation because the revocation server was offline.
Marked for [closure]: Failed HTTPS connection
....
how to solve this?
Thanks

Related

Is there a way to know whether Tracer is success fully connected to jaeger backend server in jaegerclientcpp?

In jaeger-client-cpp when I connect my Tracer variable to jaeger backend (I m using jaeger-all-in-one server) then upon successful connection LOG INFO message is shown telling me the connection is successful, but when connection is unsuccessful is just shows LOG ERROR message telling me that connection with server not successful.
So is there any way to check this programatically about the status of connection of Tracer with server.
OS-ubuntu 18.04
jaeger-client-cpp-v0.5.0
#include <jaegertracing/net/IPAddress.h>
#include <jaegertracing/net/Socket.h>
void check(){
try{
jaegertracing::net::Socket socket;
socket.open(AF_INET, SOCK_STREAM);
const std::string serverURL = configuration.sampler().kDefaultSamplingServerURL;
socket.connect(serverURL);
}catch(...){}
}
if it throws error then it is unable to reach host, this method is costly I agree but this is the only viable solution I find

Clarification needed about a SSL client using Boost asio

I have a C++ application that uses Boost_asio to do TCP/IP connection who read a .php document in a Web server that in turn uses the php script to update certain statistics.
The whole thing work as planned, but recently the server changed to use SSL (Google mandatory) and naturally, the previous connection stopped to work.
After a lot of theoretical reading about SSL, I'm still in the dark about certain practical details.
Using the example in the Boost asio documentation and a file “cacert.pem”, downloaded form somewhere following indications in this site, I'm able to run correctly the example using:
<host> = “www.google.com” and <port> = “https”.
Using the example “as is”, the Google server response is:
Verifying /OU=GlobalSign Root CA - R2/O=GlobalSign/CN=GlobalSign
Verifying /C=US/O=Google Trust Services/CN=Google Internet Authority G3
Verifying /C=US/ST=California/L=Mountain View/O=Google LLC/CN=www.google.com
Enter message: Reply:
But when using
<host> = “www.zator.com” and <port> = “https”
my domain, hosted in 1&1 IONOS, the reply is:
Handshake failed: tlsv1 alert internal error
At this point I have several questions:
What in the hell mean the sentence: ctx.load_verify_file("cacert.pem"); ?
The content of that file, can be the culprit of the fail when connecting with my domain?
Is that sentence essential to complete the connection?
In the case of google server (absence of error), is it supposed that after the sentence io_context.run(); the connection has been correctly established?
Assuming I make public the client's member socket_ (private in the example), can I continue with some as (I can't test that in google :-)
std::string request("GET /mystatistics.php HTTP/1.1\r\n\r\n");
boost::asio::write(c.socket_, boost::asio::buffer(request));
boost::system::error_code ec;
std::string response;
do { // read response
char buf[1024];
size_t bytes_transferred = c.socket_.read_some(boost::asio::buffer(buf), ec);
if (!ec) response.append(buf, buf + bytes_transferred);
} while (!ec);
std::cout << "Response received: '" << response << "'\n";
Thanks in advance.
I've found some useful information here. A good, albeit partial info, and a good start point to further search

After Successfull TLS handshake the server closes with error SSL routines:SSL3_GET_RECORD:wrong version number

We are using openssl 1.0.2k for our TLS related functionalities.
In one of our deployment the client is able to complete the TLS handshakes using TLSv1.2 and was able to send application data towards server.After some requests the TLS connections closed from the server side with the below error
"error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number"
TLS handshake steps:
1. Client hello
2. Server Hello
3. Certificate,Certificate Request, Server hello done
4. Certificate,Client Key Exchange,Change Cipher spec,Encrypted handshake message
5. Change Cipher spec,Encrypted handshake message
6. Application data exchanges between client and server
7. Encrypted Alert(server to client)
8. Encrypted Alert( client to server
The error logs from server side says "error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number"
Can you please let us know the cause for this issue. If the ssl version is mismatching then the handshake phase should not succeed right?
But in our case handshake is successful and after some application data transfer our server is failing with this error.
If the ssl version is mismatching then the handshake phase should not succeed right?
No. Any TLS packet have header, and header has TLS version inside:
(
byte - record_type
byte[2] - version
byte[2] - length
) header
byte[length] - encrypted or raw data
Header is always in raw, it is never encrypted. Even if during handshake client sent TLS 1.2 version in all TLS packets, he can send another version after handshake is finished. Or someone in between can modify network traffic. In this case OpenSSL throws described error.
In my case, I was using OpenSSL for client functionality.
I was calling SSL_set_connect_state after SSL_connect. It should be called before.
SSL_set_connect_state (for client only) cleans up all the state!
snippet:
void SSL_set_connect_state(SSL *s)
{
s->server = 0;
s->shutdown = 0;
ossl_statem_clear(s);
s->handshake_func = s->method->ssl_connect;
clear_ciphers(s);
}
In my case:
1) Client <-> Server handshake succeeded.
2) SSL_write from client side (client sending message to server) lead to exact same error as mentioned in question (on server side)
I looked at pkt dump on server side.
read from 0x2651570 [0x2656c63] (5 bytes => 5 (0x5)) .
0000 - 16 03 01 01 e2 .....
ERROR
139688140752544:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong >version number:s3_pkt.c:337:
1) 5 Bytes read in the above snipped is the size of SSL record. Server received data, and it attempted reading SSL record.
2) 1'st byte of the record is the SSL record type In this case ===> x16 => '22'
This itself is wrong, as far as server is concerned, handshake was successful and it was expecting application data. Instead it received data with SSL record for handshake, hence it was throwing the error.
A correct snippet of application data is as follows: 'x17' ==> 23
read from 0x2664f80 [0x2656c63] (5 bytes => 5 (0x5)) .
0000 - 17 03 03 00 1c
Since SSL_set_connect_state was called after connecting, client state was lost and SSL_write will attempt handshake if handshake wasnt performed before (client thought so as its state was lost!)
More data on these SSL records can be found here:
https://www.ibm.com/support/knowledgecenter/SSB23S_1.1.0.12/gtps7/s5rcd.html

SSL_Read() returns SSL_ERROR_ZERO_RETURN but ERR_get_error() is 0

I am writing a non-blocking Websocket client and using OpenSSL for the TLS layer. I am able to connect to the remote server, complete the TLS handshake, send an Upgrade request, get an upgrade confirmed response, and get an actual websocket response afterwards before the TLS layer disconnects with a SSL_ERROR_ZERO_RETURN.
SSL_get_error(...) returns: 6 // SSL_ERROR_ZERO_RETURN
ERR_error_string(ERR_get_error(), nullptr) returns: error:00000000:lib(0):func(0):reason(0)
From my understanding, ERR_get_error() should pop off and return the first error on the error queue, and SSL_get_error() returns the last error of a SSL_* function. I do not understand why SSL_get_error() would return an error value but ERR_get_error() does not. According to this previous Stack Overflow Question, SSL_get_error() does NOT call ERR_get_error().
Following code gets called repeatedly (since it is a non-blocking socket) :
ERR_clear_error();
int ret = SSL_read(...);
if (ret > 0) {
// read bytes from socket
} else {
int err_code = SSL_get_error(ssl_session_, ret);
if (err_code == SSL_ERROR_ZERO_RETURN || err_code == SSL_ERROR_SYSCALL || err_code == SSL_ERROR_SSL) {
sprintf("Disconnected: %d %s", err_code, ERR_error_string(ERR_get_error(), nullptr));
// Disconnect Code
}
}
I have two questions:
Why am I not getting an error value for ERR_get_error()?
Why am I getting disconnected so quickly after establishing a TLS and Websocket session?
EDIT 1
I used wireshark to capture the packets between the client and the server. I confirmed that the TLS handshake, the websocket upgrade, and an initial server response are successful. I noticed after the initial server response, my client gets an Encrypted Alert 21 from the server which I believe is a fatal error and explains why the TLS session terminates immediately and my SSL error queue is empty (while it is probably a client side issue, I don't think it's the result of a recent action), and kind of explains the SSL_ERROR_ZERO_RETURN value I am getting after the SSL_Read.
I am not sure what the Encrypted Alert 21 entails. It might be the cert I am using (self signed). Need to investigate further.
Alright, the root cause of the issue has been determined but a lot of hoops were jumped through and time wasted to get there. I was able to decrypt the SSL traffic by grabbing the master key using the OpenSSL method, SSL_SESSION_get_master_key(), and the Client Hello's Random value with wireshark.
Relevant Code to output master key after SSL_Connect:
ERR_clear_error();
int ret = SSL_connect(ssl_ptr);
if (ret > 0) {
SSL_SESSION * ssl_session = SSL_get_session(ssl_ptr);
if(ssl_session != NULL) {
unsigned char master_key_buf[256];
size_t outlen = sizeof(master_key_buf);
size_t buf_size = SSL_SESSION_get_master_key(ssl_session, master_key_buf, outlen);
if(outlen > 0) {
char hex_encoded_master_buf[513];
// hex encode the master key
for(size_t i = 0; i < buf_size; ++i) {
sprintf(&hex_encoded_master_buf[2*i], "%02x", master_key_buf[i]);
}
hex_encoded_master_buf[(2*buf_size)] = '\0';
// log out the hex-encoded master key in master buf here
}
}
}
Using the NSS Key Log CLIENT_RANDOM format in wireshark to decrypt the captured SSL Traffic, I was able to examine the aforementioned Encrypted Alert 21 which ended up just being a WebSocket FIN and close_notify.
It turns out, the underlying reason was that during the handshake, my WSS Upgrade Request message did indeed containing the right headers, but I was actually sending a garbage payload with it. It was a case of setting the size using sizeof of the message buffer instead of strlen when sending the message. The server would have parsed the Upgrade message just fine and completed the handshake successfully, but the next time it checked its socket, it would read in garbage when it was expecting a WSS message. This caused the abrupt closure of the websocket connection.
In Summary, to answer my original two questions:
Why am I not getting an error value for ERR_get_error()?
The connection is being terminated on the server side, and the error queue would contain errors on the client side, which there are not any, at least on the SSL/TLS layer.
Why am I getting disconnected so quickly after establishing a TLS and Websocket session?
My Initial Upgrade request contained a valid Websocket Upgrade Request with Garbage Data following it. The Server parsed the Websocket Upgrade Request and confirmed the upgrade, and started sending back data. The next time the server checked its socket, it still had the garbage values that was sent with the original Websocket Upgrade Request. Since the server did not recognize it as a valid Websocket message, or anything else for that matter, it decided to terminate the connection with a close_notify.

An exception occurred when setting up mail server parameters.: cfpop

the below code was working until a few days back, but it started giving exception
<cfpop
action="getall"
name="qMessage"
server="mail.forestweb.com"
port="995"
username="email***#industryintel.com"
password="******"
timeout="30"
/>
I am running this code every 10 minutes to fetch the emails. And getting following exceptions:
Message: An exception occurred when setting up mail server parameters.
Detail : This exception was caused by: javax.mail.MessagingException:
Connect failed; nested exception is: java.net.SocketTimeoutException: Read timed out.
Can anyone please tell me why this is happening and if it has any solutions.
The root cause for me, when I had this problem, was that my harddrive was nearly full combined with the fact that there were some invalid spool files in the spool directory.
I cleared some space on the harddrive that my cf server was on and the email started sending again.
Port 995 is typically used for SSL secured connections. Natively, CFPOP does not support SSL. However, there is a way, check out this post http://www.thecfguy.com/post.cfm/ssl-support-with-cfpop
Hope that helps.