As stated in the Symfony Docs it is possible, to add a failover configuration for mail servers:
Symfony's mailer supports high availability via a technique called "failover" to ensure that emails are sent even if one mailer server fails.
A failover transport is configured with two or more transports and the failover keyword:
MAILER_DSN="failover(postmark+api://ID#default sendgrid+smtp://KEY#default)"
The failover-transport starts using the first transport and if it fails, it will retry the same delivery with the next transports until one of them succeeds (or until all of them fail).
Is it possible to use and configure this feature in TYPO3? If so, how?
Can other configurations like TLS Peer Verification (Symfony Docs) of the Symfony mailer be configured in TYPO3?
By default, SMTP transports perform TLS peer verification. This behavior is configurable with the verify_peer option. Although it's not recommended to disable this verification for security reasons, it can be useful while developing the application or when using a self-signed certificate:
$dsn = 'smtp://user:pass#smtp.example.com?verify_peer=0';
Both features are currently not available as configuration in TYPO3. Can you please create 2 issues at https://forge.typo3.org/projects/typo3cms-core/issues?
Of course via e.g. XCLASS or maybe there is an event it is possible to add such stuff via extension.
Related
I'm trying to configure Artemis to allow connections using the CERT provided by the java client using the DN as the username. I have read almost all the documents and things I could find asking 'the google', but alas, I find myself at a frustrating stand-still.
I have the acceptor configured:
<acceptor name="netty=ssl-acceptor">tcp://0.0.0.0:5500?sslEnabled=true;keyStorePath=xxxx;keyStorePassword=xxxx</acceptor>
And on client side I am passing the CERT (or at least I think I am). Here's the URL I'm using:
tcp://mynode:5500?sslEnabled=true;useDefaultSslContext=true
I have also used this URL:
tcp://mynode:5500?sslEnabled=true;keyStorePath=xxxx;keyStorePassword=xxxx
Without posting code (different network), can anyone provide any well-known issues or hints that might be causing the server to say:
Unable to validate user from /x.xxx.xxx.xxx:xxxx. Username: null; SSL certificate subject DN: unavailable
The message you're seeing indicates that you're not passing any credentials when you connect (either username/password or SSL certificate). The reason you're not passing any credentials is because your acceptor configuration is incorrect since you're not telling clients to actually provide a certificate. You need to set needClientAuth=true, e.g.:
<acceptor name="netty=ssl-acceptor">tcp://0.0.0.0:5500?sslEnabled=true;needClientAuth=true;keyStorePath=xxxx;keyStorePassword=xxxx</acceptor>
On the client, you should only use useDefaultSslContext=true if you're explicitly configuring the default SSL context (which is rare). You most likely should be using your second options where you configure keyStorePath and keyStorePassword.
Also, keep in mind that you'll need to either use certificates signed by a trusted authority or you'll need to create and configure trust stores on your client and broker and add the proper certificates to them.
You need to set the Artemis user Preferences. Click profile account and select Preferences. If it empty, please fill out the default user first.
You need to add an extra acceptor configuration to disable the SSL. Open up etc/broker.xml and add following configuration.
<acceptor name="netty-ssl-acceptor">tcp://0.0.0.0:61617?sslEnabled=false</acceptor>
Now it should work
Converse.js successfully makes requests to Prosody bosh but the chat client never actually connects. In the console I can see it hitting the bosh endpoint and after each request it outputs to the console:
"Server did not yet offer a supported authentication mechanism. Sending a blank poll request."
I can hit the bosh endpoint from my browser as well, the proxy pass appears to be working as intended and bosh is running and responding to requests.
Any insight is much appreciated.
I came across this issue as well while using the fullpage demo. The problem was because Prosody was forcing encrypted authentication only for client side.
I recommend going into the config file /etc/prosody/prosody.cfg.lua
Look for the code
-- Force clients to use encrypted connections? This option will
-- prevent clients from authenticating unless they are using encryption.
c2s_require_encryption = true
By default for me this was set to true, change this to false
c2s_require_encryption = false
save it and reboot Prosody
systemctl restart prosody
you could also do
prosodyctl restart
The error message is quite clear. Prosody is not offering a SASL authentication mechanism supported by Converse.
By default Converse supports SCRAM-SHA1, DIGEST-MD5 and PLAIN.
Your XMPP server needs to support one of these.
The REST API for Kafka Connect is not secured and authenticated.
Since its not authenticated, the configuration for a connector or Tasks are easily accessible by anyone. Since these configurations may contain about how to access the Source System [in case of SourceConnector] and destination system [in case of SinkConnector], Is there a standard way to restrict access to these APIs?
In Kafka 2.1.0, there is possibility to configure http basic authentication for REST interface of Kafka Connect without writing any custom code.
This became real due to implementation of REST extensions mechanism (see KIP-285).
Shortly, configuration procedure as follows:
Add extension class to worker configuration file:
rest.extension.classes = org.apache.kafka.connect.rest.basic.auth.extension.BasicAuthSecurityRestExtension
Create JAAS config file (i.e. connect_jaas.conf) for application name 'KafkaConnect':
KafkaConnect {
org.apache.kafka.connect.rest.basic.auth.extension.PropertyFileLoginModule required
file="/your/path/rest-credentials.properties";
};
Create rest-credentials.properties file in above-mentioned directory:
user=password
Finally, inform java about you JAAS config file, for example, by adding command-line property to java:
-Djava.security.auth.login.config=/your/path/connect_jaas.conf
After restarting Kafka Connect, you will be unable to use REST API without basic authentication.
Please keep in mind that used classes are rather examples than production-ready features.
Links:
Connect configuratin
BasicAuthSecurityRestExtension
JaasBasicAuthFilter
PropertyFileLoginModule
This is a known area in need of improvement in the future but for now you should use a firewall on the Kafka Connect machines and either an API Management tool (Apigee, etc) or a Reverse proxy (haproxy, nginx, etc.) to ensure that HTTPS is terminated at an endpoint that you can configure access control rules on and then have the firewall only accept connections from the secure proxy. With some products the firewall, access control, and SSL/TLS termination functions can be all done in a fewer number of products.
As of Kafka 1.1.0, you can set up SSL and SSL client authentication for the Kafka Connect REST API. See KIP-208 for the details.
Now you are able to enable certificate based authentication for client access to the REST API of Kafka Connect.
An example here https://github.com/sudar-path/kc-rest-mtls
Is it possible that weblogic uses a custom ssl socket implementation? I'm running into a problem with the JavaMail. Trying to use a smtp ssl connection fails even though I've setup a custom truststore with the mailserver ca. However if I set the javax.net.ssl.trustStore property to use a truststore with the mailserver ca everything works.
This makes me think that weblogic uses their custom sockets or custom config for sockets. While JavaMail relies on the standard mechanisms and will not take into account what's in the weblogic custom truststore.
Any ideas?
(posted as an answer - thanks!)
WebLogic Server doesn't use custom socket implementation that I'm aware of. I've integrated it in the past with a number of client applications or other servers. That being said, SSL is gloriously frustrating to get working right. Can you post the exceptions/errors you're getting in your logs when WebLogic Server tries to make the connection? If you're not seeing anything in the logs, depending on the version of WebLogic Server you're using, there are a number of debug flags you can enable to get more information.
By default WebLogic uses the Certicom SSL implementation. My experience of this library has been nothing but grief. You haven't provided any details of the error but I would enable the Sun implementation to see if that helps. In the "Advanced" tab in the SSL-configuration there is a checkbox called "Use JSSE SSL" which will do it.
Or you can do it with system properties like so:
http://weblogic-wonders.com/weblogic/2010/11/09/enforce-weblogic-to-use-sun-ssl-implementation-rather-than-certicom/
Does anyone have an experience or just thoughts about securing MQ TCP
communication channels using stunnel?
I am integration with third party S.W which has MQ support built in but it can not support SSL. So to have some kind of security over the TCP we would like to use stunnel. Does any one have any thoughts how to implement and any best practices
I haven't used stunnel so I'll leave that part of the answer to another responder. With regard to WMQ, keep in mind that this will provide you with data privacy and data integrity over the stunnel link but will not give you channel-level services such as WMQ authentication. True, you will have some level of authentication on the stunnel connection itself, but anyone with a TCP route to the QMgr that does not arrive via stunnel will also be able to start that channel.
Your requirement for security obviously includes data privacy. If it also includes authentication and authorization, you might need to use something like BlockIP2 (from http://mrmq.dk )to filter incoming connections on that channel by IP address to insure they arrive over the stunnel link. Of course, there is nothing to prevent someone at the remote end from specifying any channel name to connect to so if you secure one channel, you need to secure them all - i.e. make sure that SYSTEM.DEF.* and SYSTEM.AUTO.* channels are disabled or that they use SSL and/or an exit to authenticate the inbound connection.
Finally, be aware that if WMQ is configured to accept the ID presented by the client then the connection has full administrative access and that includes remote code execution. To prevent this you must configure all inbound channels (RCVR, RQSTR, CLUSRCVR and SVRCONN) that are not administrative with a low-privileged ID in the channel's MCAUSER. For any channels that are intended for administrators, authenticate these with SSL. (Hopefully your 3rd party SW is an application and not an administrative tool! Any WMQ admin tool must support SSL or else don't use it!)
So by all means use stunnel to secure this link, just be sure to secure the rest of the QMgr or else anyone who can legitimately connect (or even anonymous remote users if you leave MCAUSER blank and aren't using SSL and/or exits) will just bypass the security or disable it.
There's a copy of the IMPACT presentation Hardening WMQ Security at https://t-rob.net/links/ which explains all this in more detail.
Rob - I agree with you. For that only we have MQIPT. Which is much better. For STunnel for MQ i have sloved the problem.
Keys -U need a .pem key (From Key manager you can create .p12 and use open ssl to covert to .PEM).
Client Side: Download and install stunnel have followoling entries in the config file
cert = XXX.pem
client = yes
[MQ]
accept = 1415
connect = DestinationIP:1415
Server Side:
cert = xxx.pem
client = no
[MQ]
accept = 1415
connect = MQIP:1415
Once you do this all you have do is just call the amquputc with the Queue name.