[THIN] Re: Securing MFXP
- From: "Marc-Andre Lapierre" <malapierre@xxxxxxxxxxxxxxxx>
- To: <thin@xxxxxxxxxxxxx>
- Date: Thu, 18 Aug 2005 12:04:06 -0400
OK you are right... but I mean, I do not validate the identity of the
connecting client like I would do with a token. I know that a private cert is
not trustable unless you use it internally. I was replying to the ". It's only
validating the end point you're connecting too. CSG is not validating you with
the cert, you are validating it..." of joe sonk. All your points are good and I
fully agree with you. But I still think that you rely only with a simple
username password solution. Anyway, in most cases, that's enough.
_____
De : Bray, Donovan (ESC) [mailto:BrayD@xxxxxxxxxxxxxxxxxx]
Envoyé : 17 août 2005 20:39
À : thin@xxxxxxxxxxxxx
Objet : [THIN] Re: Securing MFXP
Not true, when you are dealing with an Enterprise CA such as Thawte or Verisign
you have to go through verifications that your business is really who you say
you are. It validates that the Cert that was issued to said entity really
belongs to that entity. It's not a quick process to get a Cert because of this
validation. Once you have your business certified, then getting new certs is
not a problem as long as you stick with the same CA. (Entrust Certs have a much
less stringent validation process, thus they are less expensive, easier to
obtain, and they are less secure than certs from CA's such as Thawte and
Verisign, That's the business practices part I spoke of)
Why that's important is that if Company X gets a Thawte Certificate, and
another company tries to also get a Company X certificate from Thawte so that
they can impersonate your cert, they won't pass Thawtes identification process,
and be denied said cert.
If I asked your private CA : "But who are you REALLY" Your CA can only answer,
I am myself, you'll have to trust me.
If you ask a server that has a publicly available cert, They say I am Server X,
according to Thawte. I can look in my own keys and recover thawtes public key,
and say... oh why yes you are a thawte cert, so I shall trust your answer. You
can also be more pessimistic. Yes you are who you say you are, but I can check
thawte and see if your cert has been revoked. I communicate to thawte and
don't find you in the revocation list. I can be pretty well assured, you are
who you say you are.
Self Signed Certs and Untrusted CA's can be exposed to man-in-the-middle
attacks and impersonation.
You can use a self signed cert or your own untrusted CA for many reasons. But
higher security isn't among them.
Its a fallacy to believe that more complicated is more secure. In fact its
usually the opposite. Most insecurity is born of mistakes by the folks creating
it or setting it up. As complexity goes up so do your chances of mistakes.
I'll say this as well, it doesn't mean that an Untrusted CA isn't appropriate
for your situation. What are you trying to protect? You just don't want to make
it easy for the script kiddies to annoy your systems? It will probably do the
trick. If your working for a bank trying to protect online transactions, you'd
probably get fired. Where are you on the continuum?
Security costs. To be totally secure costs more than you have. The trick is
spending enough to gain appropriate levels of security for what you are trying
to protect.
_____
From: Marc-Andre Lapierre [mailto:malapierre@xxxxxxxxxxxxxxxx]
Sent: Wednesday, August 17, 2005 2:27 PM
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: Securing MFXP
I meant kind, not king.
With the use of a public CA root Cert you're not identified either. You just
use the certificate to encrypt the data with the CSG box.
_____
From: Joe Shonk [mailto:joe.shonk@xxxxxxxxx]
Sent: Wednesday, August 17, 2005 5:11 PM
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: Securing MFXP
You really can't call it the king of two factor authentication since the Root
CA does NOT identify you are who you are. Anybody who accesses the system will
use the same Root CA certificate. It's only validating the end point you're
connecting too. CSG is not validating you with the cert, you are validating
it...
Joe
_____
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf Of
Marc-Andre Lapierre
Sent: Wednesday, August 17, 2005 1:00 PM
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: Securing MFXP
But using a private cert is more secure than using a public one since the ICA
has to trust the Root certificate of the CSG box. It's a king of two factor
authentication since you need to give the private certificate to your users.
_____
From: Joe Shonk [mailto:joe.shonk@xxxxxxxxx]
Sent: Wednesday, August 17, 2005 1:26 AM
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Re: Securing MFXP
I would look at using CSG; it's more secure and free with your SubAdv. It's
much simpler to setup and maintain than SSL Relay, even with 2 servers. I
would also look into using a Public cert. They can be had for only $50 dollars
and saves a bunch of time and hassle trying to teach end users how to install
the root cert.
Joe
_____
From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On Behalf Of
ILMS (Air)
Sent: Tuesday, August 16, 2005 9:24 PM
To: thin@xxxxxxxxxxxxx
Subject: [THIN] Securing MFXP
Hii friends!
We have 2 MFXP FR3/W2k3 servers, users logging in using WI over LAN/WAN.
Would like to implement SSL.
What I have in mind is:
1. Setup CA on one MF server. Create root cert.
Issue Server cert to both MF servers (IIS servers) and install through IIS.
2. Direct WI to use HTTPS (or Citrix SSL??) on 443, also set MF server name
same a certificate name.
3. Setup citrix ssl relay on both MF servers (required??).
4. Install root cert on clients.
5. Open only 443 port.
6. Direct users to use https://server
waiting for your feedback!!
thnx in advance!
Other related posts:
