I have an OPC UA server based on open62541 that connects correctly with the client UAExpert of UnifiedAutomotion. I try to add a server certificate but the UAExpert cannot find it, even if I add it to the trust list from UAExpert>Certificate manager.
Is loaded correctly?
UA_Server *server = UA_Server_new();
UA_ServerConfig *config = UA_Server_getConfig(server);
config->serverCertificate = loadCertificate(); // Returns UA_ByteString of the file certificate.der
if(config->serverCertificate.length > 0)
UA_LOG_INFO(UA_Log_Stdout, UA_LOGCATEGORY_SERVER, "Certificate loaded");
UA_ServerConfig_setDefault(config);
I don't know if the method UA_ServerConfig_setDefault is enough for loading certificate, because the examples I have seen uses UA_ServerConfig_setDefaultWithSecurityPolicies for setting the server configuration. I tried to test the example of server_encrypted.c but when I compile it throws exceptions of libraries and glibc versions.
Thanks in advance.
Welcome to stackoverflow.
I have no experience with open6254, but the client connects using an endpoint from the list of endpoints previously read from the server. The chosen endpoint should contain a certificate and when calling createession the server resends the certificate, if both certificates are not equal, the client must cancel the process, as required by the OPC UA specifications.
Maybe one of the two certificates is not being sent by the server or they are not equals.
I think you better ask here https://groups.google.com/forum/#!forum/open62541
Related
I am implementing a Web proxy (in C), with the end goal of implementing some simple caching and adblocking. Currently, the proxy supports normal HTTP sites, and also supports HTTPS sites by implementing tunneling with HTTP CONNECT. The proxy works great running from localhost and configured with my browser.
Despite all of this, I'll never be able to implement my desired features as long as the proxy can not decrypt HTTPS traffic. The essence of my question is: what general steps do I need to take to be able to decrypt this traffic and implement what I would like? I've been researching this, and there seems to be a good amount of information on existing proxies that are capable of this, such as Squid.
Currently, my server uses select() and keeps all client ids in an fd_set. When a CONNECT request is made, it makes a TCP connection to the specified host, and places the file descriptor of both the client and the host into the fd_set. It also places the tuple of fd's into a list, and the list is scanned whenever more data is ready from select() to see if data is coming from an existing tunnel. The data is then read and forwarded blindly. I am struggling to see how to intercept this data at all, due to the nature of the CONNECT verb requiring opening a simple TCP socket to the desired host, and then "staying out of it" while the client and host set up their own SSL sockets. I am simply asking for the right direction for how I can go about using the proxy as a MITM attacker in order to read and manipulate the data coming in.
As a brief aside, this project is solely for my own use, so no security or advanced functionality is needed. I just need it to work for one browser, and I am happy to get any warnings from the browser if certificate-spoofing is the best approach.
proxy can not decrypt HTTPS traffic
You are trying to mount a man-in-the-middle attack. SSL is designed to prevent that. But - there is a weak point - a list of trusted certificate authorities.
I am simply asking for the right direction for how I can go about using the proxy as a MITM attacker in order to read and manipulate the data coming in.
You can get inspiration from Fiddler. The Fiddler has its own CA certificate (certification authority) and once you add this CA certificate as trusted, then Fiddler generates server certificates for each connection you use on the fly.
It comes with serious security consideration, your browser will trust any site. I've even seen using the Fiddler core inside a malware, so be careful
I am trying to run my IoT-client on Threadx-Os Client which doesn't have file- system/certificate trusted store kind of things like in linux. When i look into Wireshark the client closing connection with Fatal,Bad certificate error. I tried all possible options which are suggested in different forums to solve this issue. Which haven't solved my problem. The solution i tried mentioned below.
By using below API to added only above Baltimore root certificate available in cert.c.
IoTHubDeviceClient_LL_SetOption(device_ll_handle, OPTION_TRUSTED_CERT,
certificates);
it's not working for me because we don't have trusted store like linux.
ifdef SET_TRUSTED_CERT_IN_SAMPLES
// Setting the Trusted Certificate. This is only necessary on system with without
// built in certificate stores.
IoTHubDeviceClient_LL_SetOption(device_ll_handle, OPTION_TRUSTED_CERT, certificates);
endif // SET_TRUSTED_CERT_IN_SAMPLES
I need answers for two important questions.
1) Do i need to Add entire certificate string in cert.c (or) only first Baltimore root as CA root to my client.
2) Without trusted store, how client can tell to azure-cloud i have trusted root.
Any help would be appreciated.
Assume the following:
I have a WPF Application which reads a text from a file an sends the
text to my server REST API via a HTTPS and the server sends a
response which depends on the text which was send in request
The WPF Application should be the only one which gets a useful response
to this request - so the WPF Application has to show somehow to
the server, that the request is send from the application itself.
The user of the WPF Application should not be asked to enter any login credentials
What are the best practices here?
My thoughts:
the WPF Application could send a hard-coded password along with the
request which is checked on the server side - but that sounds not
like a good solution to me because the security depends on the fact that
nobody is able to sniff the HTTPS Request.
Is it possible to sniff the HTTPS Request to get the password easily?
Thanks in advance
If your server already supports HTTPS the client knows the server is trusted based on the cert it is using, so that side is handled. (client trusts server)
To ensure trust the server needs to do the same. (server trusts client) The client should hold a cert it can pass to the server so the server can verify the clients identity.
Like always this brings up the problem of how to hide the key in the client, of which there are various schemes but since the client needs to get the key eventually you cannot prevent a dedicated hacker from finding that info, only make it harder for them. (obfuscation etc)
Depending on your application the best is a simple white-list of clients allowed to connect. Some apps can do this but many cannot since they don't have the users IP's etc, but it's something else to keep in mind if it fits your use-case.
You can send a password to the server like you suggest. As long as the message is encrypted (HTTPS) your probably fine. Nothing is 100% secure. It can be intercepted via a man-in-the-middle style attack, but these are fairly rare, or at least very targeted, so it would depend on what your software does etc.
I'm using the OpenLDAP API in C to connect to an external LDAP server and retrieve certain information. However, the software needs to run behind a HTTP CONNECT corporate proxy.
OpenLDAP doesn't expose the underlying socket calls, so is there a way to use the OpenLDAP API to specify a proxy to go through?
LDAP* lp;
int res = ldap_initialize(&lp, "ldap://some-server.com:389");
... /* Can I specify a proxy server somehow here? */
ldap_sasl_bind_s(m_connection, "", LDAP_SASL_SIMPLE, &cred, NULL, NULL, NULL);
I looked through the manual and did some Googling and found LDAP_OPT_URI which is an option code that can be passed to ldap_set_option, along with a URI. The manual describes the purpose of this option as :
"Sets/gets a comma- or space-separated list of URIs to be contacted by
the library when trying to establish a connection."
That description seems a bit vague to me, but I thought it might sound like this could allow me to set a proxy URL. However, I tried it and it has no effect anyway.
So, does OpenLDAP provide some way to connect via a proxy?
Good morning,
I was going through the Postgresql configuration files, and recently noticed that there is an ssl option. I was wondering when this is required.
Say if you have an app server and a database server - not running inside a private network. If a user tries to log in, if SSL is not enabled will the app server transmit the user's password in cleartext to the database when looking up if it is a valid username/password?
What is standard practice here? Should I be setting up my DB to use SSL?
If that is the case, is there any difference in the connection settings in config/database.yml in my Rails app?
Thanks!
Like for other protocols, using SSL/TLS for PostgreSQL allows you to secure the connection between the client and the server. Whether you need it depends on your network environment.
Without SSL/TLS the traffic between the client and the server will be visible by an eavesdropper: all the queries and responses, and possibly the password depending on how you've configured your pg_hba.conf (whether the client is using md5 or a plaintext password).
As far as I'm aware, it's the server that requests MD5 or plaintext password authentication, so an active Man-In-The-Middle attacker could certainly downgrade that and get your password anyway, when not using SSL/TLS.
A well-configured SSL/TLS connection should allow you to prevent eavesdropping and MITM attacks, against both passwords and data.
You can require SSL to be used on the server side using sslhost in pg_hba.conf, but that's only part of the problem. Ultimately, just like for web servers, it's up to the client to verify that SSL is used at all, and that it's used with the right server.
Table 31-1 in the libpq documentation summarises the levels of protection you get.
Essentially:
if you think you have a reason to use SSL, disable, allow and prefer are useless (don't take "No" or "Maybe" if you want security).
require is barely useful, since it doesn't verify the identity of the remote server at all.
verify-ca doesn't verify the host name, which makes it vulnerable to MITM attacks.
The one you'll want if security matters to you is verify-full.
These SSL mode names are set by libpq. Other clients might not use the same (e.g. pure Ruby implementation or JDBC).
As far as I can see, ruby-pg relies on libpq. Unfortunately, it only lists "disable|allow|prefer|require" for its sslmode. Perhaps verify-full might work too if it's passed directly. However, there would also need a way to configure the CA certificates.
Considering data other than the password. If you use or not i pretty much a security posture issue. How safe do you need your system to be? If the connection is just over your private network then you anyone on that network can listien in. If that is acceptable that dont use SSL, I not enable it. If the connection is ove r internet SSL should be enable.
As #Wooble says. You should never send the password as cleartext in the first place you have a problem. The stanard solution in this case is to store a hash in the database and only send the hash for validation.
Here is som link about the rails part