I have a sample HSM_KW message. It has a prefix of 3 characters that determines the length of the message header. In this sample message it is 00w. So how can I convert this into a number to know the length of the header?
Sample message:
\00w2551800114193044KW13U2B9989708BC34A58AE7F2A619DEC5C0008%E\00\01IPH\00
I would suspect \00 is a 0x00 byte and that's part of message length. Header length is configurable from console and not sent in the message. I would advise to consult with Host Programmer guide and you security personnel responsible for HSM configuration.
I have a basic question on sendto:
Suppose we wish that the destination will receive a UDP packet of exactly X bytes. That means, it cannot receive a packet of less than X bytes (which is possible if sendto returns less than X bytes). Is it possible to force the sender to send exactly X bytes, or even to return an error if it is not possible? (i.e., the receiver either will get the packet of X bytes, or will not get the packet).
Edit:
If the number of bytes sent is always X, then why the return value (the number of bytes sent) might be less than the number of bytes of the sent data (as explained in
https://learn.microsoft.com/en-us/windows/win32/api/winsock/nf-winsock-sendto
) and be non-negative?
That means, it cannot receive a packet of less than X bytes (which is possible if sendto returns less than X bytes).
This will never happen on a UDP socket. From the send(2) manual page:
If the message is too long to pass atomically through the underlying protocol, the error EMSGSIZE is returned, and the message is not transmitted.
In short, the behavior you are asking for is already present by default.
I have a LR script and I am using to make a call on a REST API to download a file. The file gets downloaded successfully but I also need the value of the file size downloaded for verification purpose. Here is what i see in loadrunner console.
Action.c(50): web_custom_request("GetImage") was successful, 2373709 body bytes, 528 header bytes, 99 chunking overhead bytes.
How can I get the value 2373709?? I tried using the below code but the size it returns is a little bit different from the above mentioned and is not solving the purpose.
HttpDownLoadSize=web_get_int_property(HTTP_INFO_DOWNLOAD_SIZE);
lr_output_message("File Size %i", HttpDownLoadSize);
Any help would be appreciated. Thanks in advance for you help.
HTTP_INFO_DOWNLOAD_SIZE property stores the last HTTP response total download size. This includes total size of headers and bodies of all responses, and possible communication overhead. 2373709 body bytes is the total body size of all responses got in a particular step, so if there are several requests/responses in your custom request step, this number will be greater then the actual file size.
I'd suggest validating your response body size. There is no standard API to retrieve it though (at least, in LR 12.53, the latest available version). As far as I see, your response is chunked so I cannot suggest you any efficient methods to do this. Here is rather inefficient method based on storing the whole body to a temporary buffer (twice!):
unsigned long length = 0;
char* tmp = 0;
web_reg_save_param_ex(
"ParamName=Body",
"LB=",
"RB=",
SEARCH_FILTERS,
"Scope=Body",
"RelFrameID=1",
LAST);
web_custom_request(...);
lr_eval_string_ext("{Body}", strlen("{Body}"), &tmp, &length, 0, 0, -1);
lr_output("body length is %d", length);
lr_eval_string_ext_free(&tmp);
Also you might need to increase the maximum HTML parameter length using web_set_max_html_param_len().
However, if you had a non-chuncked non-compressed response containing Content-Length header, you could validate it more efficiently:
web_reg_find("Text=Content-Length: 2373709",
"Search=Headers",
"RelFrameID=1",
LAST);
web_custom_request(...);
I'm working on an implementation of TCP for a class and I'm wondering what the Window Size field actually mean.
I understand that the window size is the number of bytes, but does that number of bytes apply to:
the payload of the TCP Segment, not including the header or to
the entire TCP Segment, including the header?
Thus far, I've looked on Wikipedia:
RFC 793 states that:
The window indicates an allowed number of octets that the sender may
transmit before receiving further permission.
RFC 2581 states that:
receiver's advertised window (rwnd) is a receiver-side limit on the
amount of outstanding data
Neither of these make it particularly clear. Anyone?
It applies to the payload only. The sender can always transmit ACKs, FINs, RSTs, etc., with no payload.
In our Windows C++ application I am using InitializeSecurityContext() client side to open an schannel connection to a server which is running stunnel SSL proxy. My code now works, but only with a hack I would like to eliminate.
I started with this sample code:http://msdn.microsoft.com/en-us/library/aa380536%28v=VS.85%29.aspx
In the sample code, look at SendMsg and ReceiveMsg. The first 4 bytes of any message sent or received indicates the message length. This is fine for the sample, where the server portion of the sample conforms to the same convention.
stunnel does not seem to use this convention. When the client is receiving data during the handshake, how does it know when to stop receiving and make another call to InitializeSecurityContext()?
This is how I structured my code, based on what I could glean from the documentation:
1. call InitializeSecurityContext which returns an output buffer
2. Send output buffer to server
3. Receive response from server
4. call InitializeSecurityContext(server_response) which returns an output buffer
5. if SEC_E_INCOMPLETE_MESSAGE, go back to step 3,
if SEC_I_CONTINUE_NEEDED go back to step 2
I expected InitializeSecurityContext in step 4 to return SEC_E_INCOMPLETE_MESSAGE if not enough data was read from the server in step 3. Instead, I get SEC_I_CONTINUE_NEEDED but an empty output buffer. I have experimented with a few ways to handle this case (e.g. go back to step 3), but none seemed to work and more importantly, I do not see this behavior documented.
In step 3 if I add a loop that receives data until a timeout expires, everything works fine in my test environment. But there must be a more reliable way.
What is the right way to know how much data to receive in step 3?
SChannel is different than the Negotiate security package. You need to receive at least 5 bytes, which is the SSL/TLS record header size:
struct {
ContentType type;
ProtocolVersion version;
uint16 length;
opaque fragment[TLSPlaintext.length];
} TLSPlaintext;
ContentType is 1 byte, ProtocolVersion is 2 bytes, and you have 2 byte record length. Once you read those 5 bytes, SChannel will return SEC_E_INCOMPLETE_MESSAGE and will tell you exactly how many more bytes to expect:
SEC_E_INCOMPLETE_MESSAGE
Data for the whole message was not read from the wire.
When this value is returned, the pInput buffer contains a SecBuffer structure with a BufferType member of SECBUFFER_MISSING. The cbBuffer member of SecBuffer contains a value that indicates the number of additional bytes that the function must read from the client before this function succeeds.
Once you get this output, you know exactly how much to read from the network.
I found the problem.
I found this sample:
http://www.codeproject.com/KB/IP/sslsocket.aspx
I was missing the handling of SECBUFFER_EXTRA (line 987 SslSocket.cpp)
The SChannel SSP returns SEC_E_INCOMPLETE_MESSAGE from both InitializeSecurityContext and DecryptMessage when not enough data is read.
A SECBUFFER_MISSING message type is returned from DecryptMessage with a cbBuffer value of the amount of desired bytes.
But in practice, I did not use the "missing data" value. The documentation indicates the value is not guaranteed to be correct, and is only a hint for developers can use to reduce calls.
InitalizeSecurityContext MSDN doc:
While this number is not always accurate, using it can help improve performance by avoiding multiple calls to this function.
So I unconditionally read more data into the same buffer whenever SEC_E_INCOMPLETE_MESSAGE was returned. Reading multiple bytes at a time from a socket.
Some extra input buffer management was required to append more read data and keep the lengths right. DecryptMessage will modify the input buffers' cbBuffer properties when it fails, which surprised me.
Printing out the buffers and return result after calling InitializeSecurityContext shows the following:
read socket:bytes(5).
InitializeSecurityContext:result(80090318). // SEC_E_INCOMPLETE_MESSAGE
inBuffers[0]:type(2),bytes(5).
inBuffers[1]:type(0),bytes(0). // no indication of missing data
outBuffer[0]:type(2),bytes(0).
read socket:bytes(74).
InitializeSecurityContext:result(00090312). // SEC_I_CONTINUE_NEEDED
inBuffers[0]:type(2),bytes(79). // notice 74 + 5 from before
inBuffers[1]:type(0),bytes(0).
outBuffer[0]:type(2),bytes(0).
And for the DecryptMessage Function, input is always in dataBuf[0], with the rest zeroed.
read socket:bytes(5).
DecryptMessage:len 5, bytes(17030201). // SEC_E_INCOMPLETE_MESSAGE
DecryptMessage:dataBuf[0].BufferType 4, 8 // notice input buffer modified
DecryptMessage:dataBuf[1].BufferType 4, 8
DecryptMessage:dataBuf[2].BufferType 0, 0
DecryptMessage:dataBuf[3].BufferType 0, 0
read socket:bytes(8).
DecryptMessage:len 13, bytes(17030201). // SEC_E_INCOMPLETE_MESSAGE
DecryptMessage:dataBuf[0].BufferType 4, 256
DecryptMessage:dataBuf[1].BufferType 4, 256
DecryptMessage:dataBuf[2].BufferType 0, 0
DecryptMessage:dataBuf[3].BufferType 0, 0
read socket:bytes(256).
DecryptMessage:len 269, bytes(17030201). // SEC_E_OK
We can see my TLS Server peer is sending TLS headers (5 bytes) in one packet, and then the TLS message (8 for Application Data), then the Application Data payload in a third.
You must read some arbitrary amount the first time, and when you receive SEC_E_INCOMPLETE_MESSAGE, you must look in the pInput SecBufferDesc for a SECBUFFER_MISSING and read its cbBuffer to find out how many bytes you are missing.
This problem was doing my head in today, as I was attempting to modify my handshake myself, and having the same problem the other commenters were having, i.e. not finding a SECBUFFER_MISSING. I do not want to interpret the tls packet myself, and I do not want to unconditionally read some unspecified number of bytes. I found the solution to that, so I'm going to address their comments, too.
The confusion here is because the API is confusing. Ordinarily, to read the output of InitializeSecurityContext, you look at the content of the pOutput parameter (as defined in the signature). It's that SecBufferDesc that contains the SECBUFFER_TOKEN etc to pass to AcceptSecurityContext.
However, in the case where InitializeSecurityContext returns SEC_E_INCOMPLETE_MESSAGE, the SECBUFFER_MISSING is returned in the pInput SecBufferDesc, in place of the SECBUFFER_ALERT SecBuffer that was passed in.
The documentation does say this, but not in a way that clearly contrasts this case against the SEC_I_CONTINUE_NEEDED and SEC_E_OK cases.
This answer also applies to AcceptSecurityContext.
From MSDN, I'd presume SEC_E_INCOMPLETE_MESSAGE is returned when not enough data is received from server at the moment. Instead, SEC_I_CONTINUE_NEEDED returned with InBuffers[1] indicating amount of unread data (note that some data is processed and must be skipped) and OutBuffers containing nothing.
So the algorithm is:
If SEC_I_CONTINUE_NEEDED returned, check type of InBuffers[1]
If it is SECBUFFER_EXTRA, handle it (move InBuffers[1].cbBuffer bytes to the beginning of input buffer) and jump to next recv & InitializeSecurityContext iteration
If OutBuffers is not empty, send its contents to server