[THIN] Re: Securing MFXP

  • From: "Marc-Andre Lapierre" <malapierre@xxxxxxxxxxxxxxxx>
  • To: <thin@xxxxxxxxxxxxx>
  • Date: Thu, 18 Aug 2005 12:10:31 -0400

Use a public certificate with CSG. SSL relay is not mandatory.

 

  _____  

De : Bijumon Chacko [mailto:bijumon@xxxxxxxxxxxxxxxx] 
Envoyé : 18 août 2005 10:18
À : thin@xxxxxxxxxxxxx
Objet : [THIN] Re: Securing MFXP

 

The initial question is still unanswered:) helpppp..:)

 

-------------------------------

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 private CA on one MF server. Create root cert.

Issue Server cert to both MF servers (IIS servers) and install through IIS.(no 
clients connect thru internet)

 

2. Direct Web Interface 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!-

================================================

        ----- Original Message ----- 

        From: Carl Stalhood <mailto:cstalhood@xxxxxxxxxxxxx>  

        To: thin@xxxxxxxxxxxxx 

        Sent: Thursday, August 18, 2005 8:20 AM

        Subject: [THIN] Re: Securing MFXP

         

        When you connect to WI, simply double-click the padlock on the bottom 
right of IE, switch to the Certification Path tab, view the CA certificate and 
export / import the CA certificate. I'm not sure how using a private CA 
provides additional security.

         

        
  _____  


        From: thin-bounce@xxxxxxxxxxxxx [mailto:thin-bounce@xxxxxxxxxxxxx] On 
Behalf Of Marc-Andre Lapierre
        Sent: Wednesday, August 17, 2005 4:02 PM
        To: thin@xxxxxxxxxxxxx
        Subject: [THIN] Re: Securing MFXP

         

        What if you use Entrust Authority?

         

        Right now, the weakest aspect of a CSG setup is the 
username/password... If you use a private Cert that you don't give, the hacker 
has to find the Username/Password + hack/fake or whatever your private CA 
certificate, which is not that easy even with MS technology. If you use the 
public one, yes your encryption might be stronger, but anyone can get that CA 
certificate and the only wall they have in front of your network is, in most 
cases, a username/password to find. The hacker that has the knowledge/ability 
to break in a Microsoft CA certificate is probably able to break in a 
Thawte/Verisign one... While a username/password guess/try is easily feasible 
to anyone. Maybe I'm wrong, but if I have to choose, I prefer having a slightly 
week encryption (specially knowing that the content of an ICA packet is almost 
useless) with an easy to create and a private MS CA Cert than having a stronger 
encryption but easier to break in a Username Password only!

         

        
  _____  


        From: Bray, Donovan (ESC) [mailto:BrayD@xxxxxxxxxxxxxxxxxx] 
        Sent: Wednesday, August 17, 2005 4:29 PM
        To: thin@xxxxxxxxxxxxx
        Subject: [THIN] Re: Securing MFXP

         

        From a security standpoint I don't think what you are suggesting is 
entirely true. I guarantee you Thawte and Verisign run a much more secure CA, 
than the rest of us can.

         

        What you are suggesting is potentially more hoops for an attacker, but 
if the hoops are easier to get around, there's no security advantage. Also as 
stated before it increases your training costs, and ongoing TCO for additional 
helpdesk calls, that you could have reduced by paying $300/yr to a reputable 
publicly available CA.  I wouldn't consider anybody's self setup CA to be more 
secure than a reputable public CA, unless you are in the business of setting up 
Certificate Authorities and you had a considerable amount of money to invest in 
the PKI infrastructure.  Setting up a secure CA and PKI infrastructure is well 
beyond running just running Microsoft's CA software on a single box. It's about 
the business practices of the CA as much as it is about the technology.

         

        
  _____  


        From: Marc-Andre Lapierre [mailto:malapierre@xxxxxxxxxxxxxxxx] 
        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!

         

        
  _____  


        Internal Virus Database is out-of-date.
        Checked by AVG Anti-Virus.
        Version: 7.0.308 / Virus Database: 266.11.0 - Release Date: 29/04/2005

Other related posts: