I am trying to set up an XMPP server, such that users of my service can communicate with XMPP users of other services. I have two requirements
1) Users of other services must still be able to use whatever client and chat service they are currently using, such as the gmail web client, to talk to my clients.
2) The communication must be encrypted when sent between client and server and server and server. (The later is more difficult)
I setup an XMPP server and federated with gmail, and found that the server to server communications was not encrypted. I next federated my XMPP server with jabber.org, and the connection from my server to jabber.org was encrypted, giving me confidence that my server configuration was correct. Is there any way to encrypt the communication between my XMPP server and Google's Are there any XMPP servers that support TLS with Google Presuming this is not currently supported by Google, are their plans to add TLS on server to server communications in the future? When is it expected?
In lieu of encrypted server to server communications, are there other possibilities (given the above requirements)? Would a Google app engine application have encrypted communication between the gmail server and my Google app engine app and also satisfy the first requirement?
For the communication server to server, you can use AES to encrypt all the communication, and for the password, you can send it with RSA. If you are using python you can use pycrypto, although to test it in the development server have to install that library.
About the client and server comunitacion I'm not sure if you can use the same encryption.
Related
In Database Mail, I find this statement:
Database Mail is an enterprise solution for sending e-mail messages from the SQL Server Database Engine or Azure SQL Managed Instance. Your applications can send e-mail messages to users using Database Mail via an external SMTP server.
As I've been using Database Mail for over ten years, this is good to read.
However, apparently Database Mail uses the .NET SmtpClient class, which has not been kept up-to-date and even recommends "MailKit".
In Exchange Online / Deprecation of Basic Authentication, I find the following phrase:
SMTP AUTH will still be available when Basic authentication is permanently disabled on October 1, 2022.
So the obvious question is whether SQL Database Mail with SmtpClient uses "SMTP AUTH" and therefore can still connect to Exchange without an SMTP relay.
Or if a relay is needed, would the built-in Windows Server SMTP relay be able to "upgrade" the credential exchange when connecting off-site?
We have Database Mail configured using an outlook.com account, so there are definitely cases where Database Mail can send to a Microsoft-controlled email server using SMTP.
Bottom line, do we need to know anything other than that SMTP AUTH is still available?
I've done a small TCP/IP server which acts quite like an ftp server.
On the client side, I'm using an API to connect and to exchange data against the server.
This server will be on an active-directory ecosystem, so the client.
What kind of API should I use to implement a SSO/AD authentication on my server ?
(Everything is written in C)
I've seen that SqlServer is doing this through the Trusted connection term. Perhaps a simplier to do things ?
Should I lead to SSPI exchange loop ?
Yes, you need to init a security context from the client and accept that contect from the server, loop until the security context has been established. If you are concerned about your private, you can encrypt the entire traffic with Kerberos.
I am trying to secure online transaction between application server and database. One-way is SSL, but is there any other way of securing transaction between them. I am trying to reduce the overhead in securing the line. Are there any tool or api's which I can integrate with the application server or deploy on it.
/SR
Sure, but it requires a thoughtful review of your architecture. If you have a dedicated line between your application and your database, the connection could be encrypted at the network layer.
I'm a bit surprised that your application server and your database are not within the same trust boundary. Is this an app in the cloud?
SSL is by far the best way, its extremely secure and absolutely free. If your database or another application doesn't support SSL then you can use a free SSL VPN such as OpenVPN. This will create a secure transport layer connection between 2 machines.
If you are connecting to a database on the local machine then there is no point in a secure transport layer connection. However you should firewall off the database port, for instance MySQL uses tcp 3306.
I'm planning on provisioning a web server and database server in a server farm environment. They will be in the same network but not in the same domain, both windows server 2008 and the database server is sql server 2008. My question being, what is the best way to secure data in transport between the servers? I've looked into IPSEC and SSL but not sure how to go about implementing either.
As you mentioned, IPSEC is your best bet for SQL traffic (port 1433), and SSL for web traffic (port 443).
IPSEC can be enabled through Group Policy in Active Directory.
My knowledge of IPSEC is limited but I believe that the encrypted traffic is put into a tunnel, which then travels through a different port.
When IPSEC is then turned on, traffic over port 1433 can then be blocked either through an ACL or a Firewall, thus ensuring your SQL traffic is completely secure.
If you have the ability to configure Group Policy yourself you may find this link useful.
http://www.petri.co.il/configuring_ipsec_policies_through_gpo.htm
I need to transfer data daily from SQL Server (2008) to SQL Server (2005). One of the servers is located at our web host so the data will be transferred over the Internet. On the same network I would use SSIS to transfer the data, but over the Internet this is not a secure option. Is there a secure way of achieving this?
You can use SSL with SQL Server (2000/2005 Instructions / 2008 Instructions) and then force protocol encryption on the connection between both machines. You don't have to use a purchased SSL certificate either, you can use Windows Server Certificate Services to generate one - however if you do so then the CRL must be on a machine that both servers can connect to. An easy way to do this is install Certificate Services on a stand alone machine, perhaps just a VM and the configure it to embed a public DNS name for it's CRL. This doesn't have to be a machine running Certificate Services, just something you own and can upload to. Then you can generate the certificates and publish the CRL and tada, all done.
You will need to ensure the service account SQL is running as has access to the private key of the certificate it is using.
Generally it isn't recommended to have your SQL Servers exposed to the Internet, although that may be out of your control in this case. In your position I would investigate developing some separate Web Services that would perform the transfer of the data. These can then be secured using a variety of methods, such as SSL and WS-Security and other custom user permissions. If that isn't possible then blowdart's answer seems like the way to go.
You can use Service Broker:
Built into SLQ Server engine itself, no need for external process to drive communication.
Compatible protocol SQL 2005 and SQL 2008 communicate over Service Broker out-of-the box.
No need to expose either server to the internet. Through Message Forwarding you can expose
just a SQL Express, with no data on it, to the internet to act as a gateway that lets messages into the back end target.
Communication is encrypted.
Speed, the sample in the link shows how you can exchange over 5000 1k payload messages per second between commodity machines.
Unlike SSIS or replication Service Broker is a general communication framework so it won't provide support to extract the changes and to apply the changes, with conflict resolution and the like. You would have to code that part yourself.