I'm trying to verify a server's certificate before obtaining data from it using https. I'm assuming that after curl_easy_perform I should use:
long out = -1;
curl_easy_getinfo(curl, CURLINFO_SSL_VERIFYRESULT, &out)
I cannot find any documentation explaining the meaning of the value out is set to, except for an example on https://curl.haxx.se/libcurl/c/CURLINFO_SSL_VERIFYRESULT.html, which seems to be wrong (or at least contradicts my experiments).
This example suggests that the value 0 means verification failure, while any other value signifies success.
I found that 0 is actually set every time I get a response body and a sensible HTTP code (obtained using CURLINFO_RESPONSE_CODE), whereas other values I've received (1 and 19) always went together with HTTP code 0 and empty body.
Am I missing something obvious or is there no documentation for CURLINFO_SSL_VERIFYRESULT?
It seems the documentation is missing that indeed. Issue filed: https://github.com/curl/curl/issues/2400
The value depends on the TLS backend used (OpenSSL, GnuTLS, etc).
It doesn't seem to work for Windows SCHANNEL at all.
Related
Currently, I am using the below code to set parameters to retrieve data from PACS.
DcmDataset findParams = DcmDataset();
findParams.putAndInsertString(DCM_QueryRetrieveLevel, "SERIES");
findParams.putAndInsertString(DCM_SpecificCharacterSet, "ISO_IR 192");
However, just wanted to check can we provide support multiple characters set to import data at the same time, Code will look like something below, I am trying to check whether this is possible or not as I dont have the facility to verify the same.
findParams.putAndInsertString(DCM_SpecificCharacterSet, "ISO_IR 192" ,"ISO_IR 100");
I think that what you want to express is that "this Query SCU can accept responses in the following character sets". This is plainly not possible. See a discussion in the DICOM newsgroup for reference. It ends with a proposal to add character set negotiation to the association negotiation. But such a supplement has not been submitted yet, and I am not aware of anyone working on it currently.
The semantics of the attribute Specific Character Set (0008,0005) in the context of the Query Retrieve Service Class:
PS3.4, C.4.1.1.3.1 Request Identifier Structure
Conditionally, the Attribute Specific Character Set (0008,0005). This Attribute shall be included if expanded or replacement character sets may be used in any of the Attributes in the Request Identifier. It shall not be included otherwise
I.e. it describes nothing but the character encoding of your request dataset.
and
C.4.1.1.3.2 Response Identifier Structure
Conditionally, the Attribute Specific Character Set (0008,0005). This Attribute shall be included if expanded or replacement character sets may be used in any of the Attributes in the Response Identifier. It shall not be included otherwise. The C-FIND SCP is not required to return responses in the Specific Character Set requested by the SCU if that character set is not supported by the SCP. The SCP may return responses with a different Specific Character Set.
I.e. you cannot control the character set in which the SCP will send you the responses. Surprising but a matter of fact.
Sending multiple values for the attribute is possible but has different semantics. It means that the request contains characters from different character sets which are switched using Code Extension Techniques as defined in ISO 2022. An illustrative example how this would look like and what it would mean is found in PS3.5, H.3.2
What implementors usually do to avoid character set compatibility issues is configuring "the one and only" character set for a particular installation (=hospital) in a locale configuration that is configured upon system setup. It works pretty well, for e.g. an installation in Russia will very likely support Cyrillic (ISO_IR 144) or UNICODE (ISO_IR 192) or both. In case of "both", you can select the character set that you prefer for configuring your system.
I have a method. The language for this question unimportant, but here are the stubs in Java and Python so people have something to relate to:
Token getToken(long seconds){
...
}
def get_token(seconds):
...
The documentation for this method reads:
Get the current token, or a new one.
Guarantees that the returned token will be valid for at least the given amount of seconds.
Since I am not a native english speaker, the two things are puzzling me.
I would like to name the argument for my method something more saying than seconds, but it should not be too long.
I have considered the following (Python styled):
timeout_seconds
minimum_timeout_seconds
minimum_timeout
required_timeout
required_timeout_seconds
I don't think any of them are spot on, and the two of them are a bit long for my taste.
What do people prefer?
Is there a word that can express the purpose better than the ones I have used?
Secondly, the documentation for the argument reads:
The number of seconds there should at least be left until the current token expires.
If there is less than this number of seconds left until expiration, the token will be renewed automatically.
I don't feel the wording here is right. Any thoughts?
As you are dealing with tokens I'd Take the JSON Web Token (JWT) RFC as inspiration. Hence I would use
expires_in_seconds
as the variable name if keeping with Python styling.
The word "timeout" is more commonly used when an operation ceases to try to succeed in whatever it is trying to do, whereas "expires" indicates that the subject (in this case a token) is coming to the end of its period of validity.
As for the documentation I'd rather:
The number of seconds for which the token is valid.
However it does feel like the code you are using maybe trying to create it's own web token standard, which is something I would warn against! e.g. "If there is less than this number of seconds left until expiration, the token will be renewed automatically" seems odd.
I have 3 separate APIs, A, B, and C. A and B are completely independent, whereas C queries A and B to compile data together. Each API is in its own project and running on its own port (8081, 8082, and 8083, respectively).
I am able to successfully hit A and B individually AND through C...sort of. When C hits one of these endpoints, the result comes back as a glassfish.grizzlly.utils.BufferInputStream.
I've dealt with this BufferInputStream type before by using a Transform Message Component. However, doing so here simply produces an error, saying that payload.id is of the wrong type (it should be an integer). When running this in debug mode, I can see that A has an Output Payload with id: Integer (it is of a custom type). However, upon moving back into C's flow, the payload is now the aforementioned BufferInputStream type, and I'm unable to directly access payload.id.
In short: How do I retrieve data in one project from another project?
Thanks in advance!
Update:
I used an Object to String transformer on the BufferInputStream to get a better look at the value. It appears to be in the format of a URL:
id=12345&name=nameValue&otherVal=%5B8499%5D...
I can #[payload.split('&')] at this point and get most of what I need, but then there's still the issue of things like the following:
summary=Words+with+plus+signs+in+the+middle
Again, I can work around this with things like split, but surely this is not what is intended.
Update 2:
I discovered the following warning:
[[test].api-httpListenerConfig.worker.01]
org.mule.module.http.internal.listener.HttpResponseBuilder:
Payload is a Map which will be used to generate an url encoded http body but
Contenty-Type specified is application/java; charset=windows-1252 and not
application/x-www-form-urlencoded
I'm not entirely sure what to do with that info, though the Contenty-Type typo is interesting ^^
Solved! In A and B, I needed to use an Object to Byte Array transformer before returning the value. This allows me to use a Byte Array to Object transformer in C and get the original value back.
I have implemented this http://jacob.jkrall.net/totp/ in vbscript.
My code given the same hex gives the right 6-digit otp, so that part is working.
I've also verified the HMAC-SHA-1. encoding against an online generator, http://www.freeformatter.com/hmac-generator.html#ad-output, same input gives same output.
My time is the same as http://www.currenttimestamp.com/
I've generated a qrcode at http://www.qr-koder.dk/ with the string otpauth://totp/$LABEL?secret=$SECRET and the google authenticator app reads the code and starts outputting the 6 digit code changing every 30 seconds.
BUT THE CODES FROM THE APP DOES NOT MATCH THE 6-DIGIT CODE THE VBSCRIPT GENERATES!
I've even tried trunc(time/30) +/-7500 steps to see if it was a timezone/daylight saving problem, to no avail.
As the other parts of the routine to generate the 6 digits seem to work I've come to the conclusion I don't understand this:
the url on the qr-code is
otpauth://totp/$LABEL?secret=$SECRET
with the explanation
LABEL can be used to describe the key in your app, while SECRET is the
16-character base32-encoded shared secret, which is now known to both
the client and the server.
So when I calculate HMAC-SHA-1(SECRET, time()/30)
should the SECRET be the same string given to both the app and the calculation?
If I select a secret of 1234567890, the base32 is GEZDGNBVGY3TQOJQ according to http://emn178.github.io/online-tools/base32_encode.html.
Should I then take
HMAC-SHA-1("1234567890", time()/30)
or
HMAC-SHA-1("GEZDGNBVGY3TQOJQ", time()/30)
?
I believe I've tried both, and neither works.
The system unix time is correct.
I guess the problem might be with the secret in your HMAC-SHA-1 function. It very much depends on what the HMAC-SHA-1 expects.
Your string "123456790" might be a binary string. Is it an ascii representation or utf8? I.e. is this string 10 bytes or 20 bytes long?
I recommend getting the input string in your VBScript right.
On the other hand, instead of writing your own VBScript, you can also use a ready made solution like the privacyIDEA authentication server, which is open source and also comes with TOTP.
Ok after experimenting a little bit I found out that resin was calling my AbstractAuthenticator implementation "authenticate" method that takes an HttpDigestCredentials object instead of DigestCredentials (still don't know when is called each one of them) the problem is that HttpDigestCredentials doesn't have a getDigest() method, instead it has a getResponse() method which doesn't return a hash or at least not a comparable one.
After creating my own hash of [[user:realmassword] [nonce] [method:uri]] the hash is very different, in fact I think getResponse() does not return the digest but maybe the server response to the browser?.
Any way this is my debugging log :
USER:user:PASSWORD:password:REALM:resin:METHOD:GET:URI/appe/appe.html:NONCE:HsJzN+j+GQD:CNONCE:b1ad4fa1ba857cac88c202e64528bc0c:CLIENTDIGEST:[B#5dcd8bf7:SERVERDIGEST:I4DkRCh21YG2Mk14iTe+hg==
as you can see both the supposed client nonce is very very different from the server generated nonce, in fact the client nonce doesn't look like a MD5 hash at all.
Please has someone does this before? is there something missing in the HttpDigestCredentials? I know digest is barely used.
Please, I know about SSL but I can't have an SSL certificate just yet so don't tell me "Why don't you use SSL". ;)
Update:
Not sure if was the right thing to do but, as I read before Resin uses base64 format for hashes so I used apache commons-codec-1.6 to use encodeBase64String() method and now the hashes look alike but they are no the same.
I tried both passwordDigest.getPasswordDigest(a1+':'+nonce+':'+a2); passwordDigest.getPasswordDigest(a1+':'+nonce+':'+ncount+':'+cnonce+':'+qop+':'+a2);
and none of them gives the same hash as the one from HttpDigestCredentials.
Ok I finally made it . Weird subject Huh, only two views?
First, digest authentication makes use of user, password, realm, nonce, client_nonce, nonce_count, method, qop, and uri. Basically it uses the full digest spec. So in order to calculate the hash one must calculate it with all the whistles. Is just a matter of calling the get method for each one of the variables from HttpDigestCredentials except for user and password. The user will come in the form of a Principal and the password you must look for it yourself in your DB (in my case a DB4O database).
Then you must create a PasswordDigest object, that will take care of generate a hash with the getPasswordDigest() method, but first one must set the format to hex with passwordDigestObject.setFormat("hex").
There is one for the HA1 getPasswordDigest(user,password,realm) and there is another getPasswordDigest() method that takes just one string and one can use it to generate the rest of the hashes, both HA2 and with the previous hashed HA1 the final hash, of course with the nonce nonce_count client_nonce and qop, of course each one separated by a semicolon.
Then it comes the tricky part, although resin works with base64 encoding for digest when you call the getResponse() method from HttpDigestCredentials it returns a byte array (which is weird) so in order to compare it with your hash what I did was use the Hex.encodeHexString() method from org.apache.commons.codec.binary.Hex and pass the HttpCredentialsDigest getResponse() return value, and that will give a nice hex String to compare.
I was doing it the other way around, I was using the Base64 hash from PasswordDigest and converting the HttpDigestCredentials hash to Base64 and the resulting string were never the same.