The cookie exchange initiated by HelloVerifyRequest described in section 4.2.1 of RFC 6347 is essential to DoS-protection in DTLS. Unless I'm overlooking something, the WolfSSL documentation does not really describe how to enable this cookie exchange with its DTLS implementation.
The closest I can find is the function wolfSSL_send_hrr_cookie, about which the manual states:
This function is called on the server side to indicate that a
HelloRetryRequest message must contain a Cookie. The Cookie holds a
hash of the current transcript so that another server process can
handle the ClientHello in reply. The secret is used when generting the
integrity check on the Cookie data.
As far as I understand, the HelloRetryRequest (compare HelloVerifyRequest) is TLS 1.3 terminology. DTLS 1.3 is not finalized. How does one enable and control the DTLS 1.0/1.2 cookie exchange in WolfSSL?
The DTLS Hello Cookie is enabled by default. The wolfSSL server code uses the callback function EmbedGenerateCookie() in the file src/wolfio.c to generate the cookie per the recommendation in RFC 6347 ยง4.2.1.
TLSv1.3's hrr_cookie is something else unrelated.
Related
I am now facing a design question. I have made a shared library which can be used to send HTTP requests to my HTTP server. It offers GET, POST, PUT and DELETE APIs, so the user can use them to send requests directly. However, someone else can also use TCP/IP to send their own HTTP requests to my server.
My question is, how can I check if a request comes from my library or not?
Can anybody give me some suggestion?
You can use any "standard" method of authentication to verify that the requester is who they are supposed to be. Once you've determined the authenticity, provide the requester with a short term cookie that they must send with all requests. Reject any request that doesn't hold a valid cookie (except attempts to authenticate).
Technically this doesn't prevent requests from coming elsewhere other than your library. It merely restricts requests from sources that don't know your secret. But if you don't share the secret with anyone else, then you can limit yourself to only using your library which achieves the limitation to the library indirectly.
I have an issue i don't understand.
I make an api call from a.b.com to a.b.com
In devtools I can see the request and I can see it contain cookie as expected.
Then I make the same api call from my local host to a.b.com and the cookie is not present.
As per my knowledge and online documentation search, cookie should be sent to server if it matches all its rules (domain, path, expires, etc.)
If so why the request is different for each origin?
We use CORS calls all the time.
In addition just to verify, I disabled Chrome 3rd party cookie protection.
Here is an image to provide more details:
Don't be shy to point me to good documentation on this matter :)
Due to security reasons you cannot share cookies between two different domains. You cannot exchange cookies between localhost and a.b.com.
Is there any way to pass cookie to IWebBrowser's Navigate method.
As far as I can see neither passing Cookie header in headers nor InternetSetCookie/InternetSetCookieEx works with IE11.
The only working method I found is to set cookie via put_cookie of IHTMLDocument2, but for that you have to load page first.
Is there any way to pass cookie to first call of Navigate?
You could try IESetProtectedModeCookie if you are interacting with low-integrity browser controls. This still has limitations as noted in this cookie FAQ:
IE10+ on Windows 8+ introduced Enhanced Protected Mode which uses
AppContainers (rather than Integrity Levels) for isolation. EPM does
not offer an API for interacting with cookies;
IESetProtectedModeCookie will not set the cookie inside an
AppContainer.
Creating AppContainers is not documented so I assume your process is not running in a AppContainer?
This newsgroup thread confirms that you cannot set a cookie in the headers:
In case anybody is interested, I went through Microsoft support to
find out more about this. Their answer: what I want to do is not
supported. The 'headers' argument to Navigate/Navigate2 CANNOT be
used to set cookies.
I'm guessing that refreshing the page after put_cookie is unacceptable?
I've done a C++ based HTTP server (or to rephrase - spilled another drop in the ocean) and encountered an issue with HTTP digest authentication.
According to the HTTP authentication RFC using the nextnonce directive in the Authentication-Info header is a valid way of implementing a single use nonce mechanism. I've done this according to the RFC but both Chrome and Firefox seem to ignore the directive and issue all further requests with the initial nonce thus triggering unneeded 401 responses. An example illustration with Firefox:
First request - my server returns 401 and issues the initial nonce a1f778b2afc8590e4a64f414f663128b
Firefox successfully authenticates and gets a reply with the Authentication-Info: nextnonce="0b72e74afbcab33a5aba05d4db03b801" header
Firefox issues a new request to fetch image from the returned html - still the initial nonce c1587dd7be6251fa715540e0d6121aa5 is used and thus a reply with a new nonce and a flag that the provided nonce is expired is sent back.
Same scenario as for the first image request.
Now authentication succeeds with the new nonce.
The authentication succeeds for the second request as well.
As can be seen in the images - even though I reply with Authentication-Info: nextnonce="0b72e74afbcab33a5aba05d4db03b801" upon a successful authorization on the first request the next two requests still use the original nonce instead of the provided nextnonce value. Has anyone had a similar experience? I am most certainly doing something wrong - even though the RFC says that the client SHOULD reply with the provided nextnonce value and thus it is not mandatory I highly doubt that the most popular browsers do not use this technique.
Looks like it's a known Firefox bug that's been open since 2001.
Bug 150605 - digest authentication problem: Mozilla ignores the nextnonce parameter of Authentication-Info Response Header.
which is a duplicate of
Bug 116177 - next nonce digest auth test fails
Here is the situation, we have a site that is hosted and updated by a third party vendor. I am providing links to additional resources that are hosted on our servers. A client will access the vendor site and click on a link to gain access to our additional resources. To validate that the request came from our third party vendor I need to get the IP address of the vendors server.
My question is, is there a way to get the IP address of the vendors servers using ColdFusion? I can't use the clients IP address, I need the vendor server address the client is using.
You have to work with 3rd party to accomplish this goal, this is for sure.
I can see at least two more or less working approaches here.
(1) Append some kind of protection token to the links. Your vendor generates encrypted string or hash including some information only you two know, so you can decrypt (or generate same hash) and validate it.
Example with hashing:
moment = DateConvert("local2utc", Now());
token = Hash("SecretSaultYouBothKnow" & DateFormat(moment, "yyyy-mm-dd") & TimeFormat(moment, "-HH-mm"));
This token is passed with link and expires quickly to prevent sharing/leaking.
You can generate and validate it on your side.
It's a raw idea and there could be possible problems with validation, plus avoiding invalid links for clients (maybe skip "mm" mask as well).
Encrypted/decrypted string would work similarly. You both just need to now the secret key.
By the way, your vendor could encrypt their server IP address or other identifier for you to check it against your database and maybe apply some other actions.
(2) Your vendor could set up simple web-service for you to validate the incoming links (it could respond with 0/1 or something else simple).
Exact implementation may be different. Again, it could be some token in URL which you send back for validation.
This is similar to solution which Jason suggested: vendor could send the server-to-server request to your server on link click and then relocate to the resource. But this may be complicated because you have to be sure 1st request is already handled when client arrives.
Hope these ideas make sense.
No, there isn't. Not if the request comes directly from the client. If the vendor sends some sort of a message first you can use that to validate. Or if the vendor's server is the one making the request on behalf of the client then you could use CGI.REMOTE_ADDR. But if the vendor is just providing a link to your site, then no, you cannot be assured of the IP of the vendor's server.
The closest you could come is to check the HTTP_REFERER, as Jeremy said above, but that can be spoofed (very easily), so it wouldn't be very secure.
To access the CGI variables available to ColdFusion, you can do something like this:
<cfset ThisIP = CGI.SERVER_NAME>
There are many useful CGI variables available here:
http://www.perlfect.com/articles/cgi_env.shtml
try placing a page on your server that uses the cfhttp tag to fetch:
http://www.dslreports.com/whois
That will give you the IP address of the web server.