We have ported an app which was using OpenSSL to mbel TLS. The one issue with mbel TLS is the documentation which is far from complete and leaves details to assumption or exploration and risk of how things will change in future versions.
While we already ported, we still not clear on which initialization functions to be invoked one time and which initialization functions to be performed for every connections. Based on sample application, we are invoking following initialization functions for every connection.
mbedtls_ctr_drbg_init( &ctr_drbg );
mbedtls_net_init( &server_fd );
mbedtls_ssl_init( &ssl );
mbedtls_ssl_config_init( &conf );
mbedtls_x509_crt_init( &ca );
mbedtls_entropy_init( &entropy );
Can someone comment if all these initialization functions to be invoked for every connection or some can be just one time only?
Thanks
If you follow the ssl_pthread_server example, you will see that only the mbedtls_ssl_context should be different per connection. The rest should be common for all connections, thus initiated once.
Regards,
Mbed TLS Team member
Ron
Related
I could not find in the docs the canonical way to check whether given credentials can be used to clone given repository. There is an issue that suggests that one way may be to check whether git_cred_acquire_cb() is called more than once. Can somebody confirm this or point out another way?
This is the suggested way. If your credential callback is called a second time, then the first credentials that you provided were not accepted. This pattern is primarily useful for UI applications (popping up a modal username/password dialog).
You can use the callback data to count the number of times you were called.
I realize that this may be imperfect, especially if you're binding libgit2 in another language. Setting up a data struct on the heap and managing its lifecycle is not always trivial.
You may also be able to just provide credentials and wait for a GIT_EAUTH return code. In theory, the various transport mechanisms should give up after several authentication failures no matter what. However, we found at least one bug in the 0.27 releases that would loop forever. Hence the suggestion.
Using Geode 1.2 and 9.1 Pivotal native client the following code:
IRegion<string, IPdxInstance> r = cache.GetRegion<string, IPdxInstance>("myRegion");
return r[key];
then triggers an AfterCreate event for myRegion. Why does that happen when no data is created, only read?
Same here, never used Native Client. I agreed with what #Urizen suspected - you are calling r[key] from an instance of Geode that doesn't have the entry, so it pulls the data from other instance, which "create" the entry locally.
You have a few options here:
Performing an interest registration for the instance you are initiating the call using registerAllKeys() (doc here). There is a catch here: (might not be applicable for native client), in Java API, you have an option to register interest with an InterestResultPolicy. If you use KEYS_VALUES, you will load all data to local from remote on startup WITHOUT triggering afterCreate callback. If you choose KEYS only or NONE, you will likely have similar problem.
You can check for boolean flag remoteOrigin in EntryEvent. If it is false, it is purely local. In a non-WAN setup, this should be enough to distinguish your local operation from remotely initiated operation (be it a cache syncing or a genuine creation initiated by other cache). Vaguely remembering WAN works a bit different here.
I've never used the Native Client but, at a first glance, it should be expected for the afterCreate event to be invoked on the client side as the entry is actually being created on the local cache. What I mean is that the entry might exists on the server but, internally, the client needs to retrieve it from the server, and then create it locally (thus invoking the afterCreate for the locally installed CacheListener). Makes sense?.
I was wondering if it was possible to keep an RFC called via JCO opened in SAP memory so I can cache stuff, this is the scenario I have in mind:
Suppose a simple function increments a number. The function starts with 0, so the first time I call it with import parameter 1 it should return 1.
The second time I call it, it should return 2 and so on.
Is this possible with JCO?
If I have the function object and make two successive calls it always return 1.
Can I do what I'm depicting?
Designing an application around the stability of a certain connection is almost never a good idea (unless you're building a stability monitoring software). Build your software so that it just works, no matter how often the connection is closed and re-opened and no matter how often the session is initialized and destroyed on the server side. You may want to persist some state using the database, or you may need to (or want to) use the shared memory mechanisms provided by the system. All of this is inconsequential for the RFC handling itself.
Note, however, that you may need to ensure that a sequence of calls happen in a single context or "business transaction". See this question and my answer for an example. These contexts are short-lived and allow for what you probably intended to get in the first place - just be aware that you should not design your application so that it has to keep these contexts alive for minutes or hours.
The answer is yes. In order to make it work, you need to implement two tasks:
The ABAP code needs to store its variable in the ABAP session memory. A variable in the function group's global section will do that. Or alternatively you could use the standard ABAP technique "EXPORT TO MEMORY/IMPORT FROM MEMORY".
JCo needs to keep the user session between calls. By default, JCo resets the backend-side user session after every call, which of course destroys all data stored in that user session memory. In order to prevent it, you need to use JCoContext.begin() and JCoContext.end() to get a stateful RFC connection that keeps the user session alive on backend side.
Sample code:
JCoDestination dest = ...
JCoFunction func = ...
try{
JCoContext.begin(dest);
func.execute(dest); // Will return "1"
func.execute(dest); // Will return "2"
}
catch (JCoException e){
// Handle network problems, ABAP exceptions, SYSTEM_FAILUREs
}
finally{
// Make sure to release the stateful connection, otherwise you have
// a resource-leak in your program and on backend side!
JCoContext.end(dest);
}
I'm writing a mod in Forge 1.8 and I'm making use of the SidedProxy system. I added some items/blocks for testing, but my mod mostly needs to control logic on the server side of things/write and read some data when saving.
From my understanding, in a minecraft game, there is always a server, which in singleplayer is the internal server. However, when running from eclipse, the ServerProxy never runs as I see no output from the print statement, and the block handler doesn't get registered.
To be clear, I currently have an event handler that detects block break and place events. It works when on the commonProxy or clientProxy. However, I need this to be on the logic side, whether that be on the Dedicated Server or Internal Server, which should be in the ServerProxy.
I learned that in Forge, the internal/integrated server is counted as Side.Client and SidedProxy will use the ClientProxy for it. So in order to create logic based events, you can use if(!event.world.isRemote) inside of your event handlers in order to check if it is a server that's running the code.
Answer on MinecraftForge Forums
The Tripple Handshake Issue was disclosed lately. Wether disabling session resumption will mitigate this or not, is a topic for another question. Let's assume I want to disable it for whatever reason (basicly my paranoia).
To disable this in C, it seems like one should use this:
SSL_CTX_set_session_cache_mode(ctx, SSL_SESS_CACHE_OFF);
Can someone please confirm this?
But how to do this in pyopenssl?
Starting with pyOpenSSL 0.14 this is possible:
from OpenSSL.SSL import TLSv1_2_METHOD SESS_CACHE_OFF, Context, Connection
ctx = Context(TLSv1_2_METHOD)
ctx.set_session_cache_mode(SESS_CACHE_OFF)
conn = Connection(ctx, ...)
Earlier versions of pyOpenSSL do not expose these APIs.
If you also need to turn off session tickets then:
from OpenSSL.SSL import OP_NO_TICKET
...
ctx.set_options(OP_NO_TICKET)
Can someone please confirm this?
I believe Dr. Henson answered this over at the OpenSSL User Mailing list.
the attack described in https://secure-resumption.com/ breaks also tls
channel binding tls-unique RFC 5929.
I would still like to use tls-unique for channel binding as defined in
SCRAM (RFC 5802). Can OpenSSL be used for channel binding and protect
against this attack if the session caching is disabled?
SSL_CTX_set_session_cache_mode(ctx, SSL_SESS_CACHE_OFF)
Is it necessary to disable resumption using a different function?
You'd also need to disable session tickets too.
Note the initiial phase of the attack requires that the attacker
possess a private key and certificate the client trusts. I'd be
interested to know how that could happen under your circumstances.
So, according to Dr. Henson, you also need to call SSL_CTX_set_options with SSL_OP_NO_TICKET. See the OpenSSL docs at
SSL_CTX_set_options(3).
I don't know how to do it in Python, though.