|
Home > Archive > IIS Server Security > February 2005 > is HTTPS crackable
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
is HTTPS crackable
|
|
| seeker01@gmail.com 2005-02-15, 2:54 am |
| Dear all,
The current project that I am working on is implementing OWA5.5 to be
accessible on the internet.
The architecture model that I am thinking of proposing to the
management is to configure ISA 2000 server (sits at the internal
network) to accept the HTTPS packet from PIX firewall; then forward
HTTPS to OWA & CA server (which both sits at the internal network).
This model will be tested because I am not an expert on ISA yet.
But what concerns me more at the moment is "HTTPS crackable" by hackers
and how that can happen?
Thank you in advanced for your help.
Regards,
Seeker
| |
| Ken Schaefer 2005-02-15, 8:03 am |
| If you are using 128-bit SSL, then it is generally accepted that it is not
possible, with projected computing power, that you can retrieve the plain
text within any reasonable amount of time.
HOWEVER
a) you need to keep the private key for your certificate secure
b) if someone can compromise either the client machine, or the server
machine, then they may be able to retrieve the plain text before/after it
has been encrypted/decrypted
Basically SSL is a tried and tested method of preventing Man-In-The-Middle
attacks, and also for preventing snoopers from recovering the original data.
However, it's only designed to do that, and you're only as secure as your
weakest link. You need to secure everything else as well.
Cheers
Ken
<seeker01@gmail.com> wrote in message
news:1108451618.516937.83460@c13g2000cwb.googlegroups.com...
> Dear all,
>
> The current project that I am working on is implementing OWA5.5 to be
> accessible on the internet.
>
> The architecture model that I am thinking of proposing to the
> management is to configure ISA 2000 server (sits at the internal
> network) to accept the HTTPS packet from PIX firewall; then forward
> HTTPS to OWA & CA server (which both sits at the internal network).
>
> This model will be tested because I am not an expert on ISA yet.
>
> But what concerns me more at the moment is "HTTPS crackable" by hackers
> and how that can happen?
>
> Thank you in advanced for your help.
>
> Regards,
> Seeker
>
| |
| Jeff Cochran 2005-02-15, 8:03 am |
| On 14 Feb 2005 23:13:38 -0800, seeker01@gmail.com wrote:
>The current project that I am working on is implementing OWA5.5 to be
>accessible on the internet.
>
>The architecture model that I am thinking of proposing to the
>management is to configure ISA 2000 server (sits at the internal
>network) to accept the HTTPS packet from PIX firewall; then forward
>HTTPS to OWA & CA server (which both sits at the internal network).
>
>This model will be tested because I am not an expert on ISA yet.
>
>But what concerns me more at the moment is "HTTPS crackable" by hackers
>and how that can happen?
Everything is crackable, given the time and money. The vulnerability
in your case would be a compromise of the OWA or cert server, but if
that's the case cracking HTTPS would be a non-issue. Use 128 bit and
it's pretty much guaranteed secure from an end-to-end transmission
point. As long as the rest is secure you're in no worse shape than
the majority of financial institutions out there.
Jeff
| |
| Bob Christian 2005-02-15, 8:53 pm |
| > Everything is crackable, given the time and money.
I have two words for you: squeamish ossifrage =^)
Your worry is probably not the certificate, but the system itself. OWA 5.5
is based upon the older Exchange 5.5 and NT4 (W2K) technology. You actually
risk a greater chance of having the server hacked/cracked than you do having
HTTPS / SSL compromised. Most of the NT4 hacking information is out there,
most of the patches are out there, and all of it is old (Rain Forest Puppy
had a great guide for hacking your own IIS servers back in the day).
In some cases you may find that your users can utilize an external machine
(such as an internet cafe) and their keystrokes are logged. Another item
that you have to worry about is that the secure pages may be cached to disk
unsecured (internet cafe', friends house, etc) and the session may not even
be closed out when they leave, allowing someone to open a browser and
connect back to your system.
My suggestion is to look at an Active Directory infrastructure with Exchange
2003. Your users will really like it, as compared to Exchange 5.5 and OWA
5.5
My $0.02,
Bob
"Jeff Cochran" <jeff.nospam@zina.com> wrote in message
news:4214daf6.30870068@msnews.microsoft.com...
> On 14 Feb 2005 23:13:38 -0800, seeker01@gmail.com wrote:
>
>
> Everything is crackable, given the time and money. The vulnerability
> in your case would be a compromise of the OWA or cert server, but if
> that's the case cracking HTTPS would be a non-issue. Use 128 bit and
> it's pretty much guaranteed secure from an end-to-end transmission
> point. As long as the rest is secure you're in no worse shape than
> the majority of financial institutions out there.
>
> Jeff
| |
| seeker01 2005-02-16, 5:52 pm |
| Many thanks to all of you sharing your valuable views. I would love to
upgrade to AD model too but wont happen just yet because of $$$. So far my
proposal is done just according to theory, I need to test the concept in the
lab.
"Bob Christian" wrote:
> I have two words for you: squeamish ossifrage =^)
>
> Your worry is probably not the certificate, but the system itself. OWA 5.5
> is based upon the older Exchange 5.5 and NT4 (W2K) technology. You actually
> risk a greater chance of having the server hacked/cracked than you do having
> HTTPS / SSL compromised. Most of the NT4 hacking information is out there,
> most of the patches are out there, and all of it is old (Rain Forest Puppy
> had a great guide for hacking your own IIS servers back in the day).
>
> In some cases you may find that your users can utilize an external machine
> (such as an internet cafe) and their keystrokes are logged. Another item
> that you have to worry about is that the secure pages may be cached to disk
> unsecured (internet cafe', friends house, etc) and the session may not even
> be closed out when they leave, allowing someone to open a browser and
> connect back to your system.
>
> My suggestion is to look at an Active Directory infrastructure with Exchange
> 2003. Your users will really like it, as compared to Exchange 5.5 and OWA
> 5.5
>
> My $0.02,
>
> Bob
> "Jeff Cochran" <jeff.nospam@zina.com> wrote in message
> news:4214daf6.30870068@msnews.microsoft.com...
>
>
>
| |
| seeker01 2005-02-16, 5:52 pm |
| Hi all,
For public workstation like Internet cafe, would the user be warned to
download the self-signed certificate? Personally would you encourage me to
force them to install the certificate on public workstation? Thank you once
again.
Seeker01
"Bob Christian" wrote:
> I have two words for you: squeamish ossifrage =^)
>
> Your worry is probably not the certificate, but the system itself. OWA 5.5
> is based upon the older Exchange 5.5 and NT4 (W2K) technology. You actually
> risk a greater chance of having the server hacked/cracked than you do having
> HTTPS / SSL compromised. Most of the NT4 hacking information is out there,
> most of the patches are out there, and all of it is old (Rain Forest Puppy
> had a great guide for hacking your own IIS servers back in the day).
>
> In some cases you may find that your users can utilize an external machine
> (such as an internet cafe) and their keystrokes are logged. Another item
> that you have to worry about is that the secure pages may be cached to disk
> unsecured (internet cafe', friends house, etc) and the session may not even
> be closed out when they leave, allowing someone to open a browser and
> connect back to your system.
>
> My suggestion is to look at an Active Directory infrastructure with Exchange
> 2003. Your users will really like it, as compared to Exchange 5.5 and OWA
> 5.5
>
> My $0.02,
>
> Bob
> "Jeff Cochran" <jeff.nospam@zina.com> wrote in message
> news:4214daf6.30870068@msnews.microsoft.com...
>
>
>
| |
| Phil Agcaoili 2005-02-17, 2:47 am |
| "seeker01" wrote:
> Hi all,
>
> For public workstation like Internet cafe, would the user be warned to
> download the self-signed certificate? Personally would you encourage me to
> force them to install the certificate on public workstation? Thank you once
> again.
>
> Seeker01
The vastly more secure way to protect your OWA server and accounts in this
scenario is to deploy an SSL VPN in front of your OWA server and use a
2-factor authentication token such as RSA SecurID.
Fine, have a keylogger on the Cyber Cafe machine and pick off the user's
PIN, but the hacker doesn't have your token and thre rest of your logon
credentials.
| |
| David Wang [Msft] 2005-02-17, 7:52 am |
| No, I personally encourage you to heed Bob Christian's earlier advice and
abandon your OWA 5.5 deployment plans.
If you are asking "is HTTPS crackable" yet want to implement OWA5.5 for
public Internet access by a kiosk, your security emphasis is seriously
misplaced. Kiosk access will be the weak point for several reasons (as he
listed) and will be a far easier target than HTTPS -- yet strangely, you are
more concerned about HTTPS being cracked. Hackers go for low-hanging
fruit -- easiest exploit to get the maximum damage is the first choice.
Regarding your self-signed certificate -- of course the user will be warned
about downloading and installing the self-signed certificate. If they are
not, that would be a security vulnerability in the browser to allow a remote
site to add trusted certificates. Additional problems:
1. You presume the user can even install the self-signed certificate on the
kiosk (a kiosk that gives users such permissions is probably more dangerous
to your data security)
2. You also presume that making users used to installing random certificates
into the root store of their browser is a good security behavior.
Really, the money you are saving is not worth the security risk you are
taking on as well as the unsupported software you are investing in. Security
of HTTPS infrastructure is simply the least of your concerns right now.
--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"seeker01" <seeker01@discussions.microsoft.com> wrote in message
news:6E9D6307-FFDF-44D0-A4FD-84AD5B52AC2A@microsoft.com...
Hi all,
For public workstation like Internet cafe, would the user be warned to
download the self-signed certificate? Personally would you encourage me to
force them to install the certificate on public workstation? Thank you once
again.
Seeker01
"Bob Christian" wrote:
> I have two words for you: squeamish ossifrage =^)
>
> Your worry is probably not the certificate, but the system itself. OWA
5.5
> is based upon the older Exchange 5.5 and NT4 (W2K) technology. You
actually
> risk a greater chance of having the server hacked/cracked than you do
having
> HTTPS / SSL compromised. Most of the NT4 hacking information is out
there,
> most of the patches are out there, and all of it is old (Rain Forest Puppy
> had a great guide for hacking your own IIS servers back in the day).
>
> In some cases you may find that your users can utilize an external machine
> (such as an internet cafe) and their keystrokes are logged. Another item
> that you have to worry about is that the secure pages may be cached to
disk
> unsecured (internet cafe', friends house, etc) and the session may not
even
> be closed out when they leave, allowing someone to open a browser and
> connect back to your system.
>
> My suggestion is to look at an Active Directory infrastructure with
Exchange
> 2003. Your users will really like it, as compared to Exchange 5.5 and OWA
> 5.5
>
> My $0.02,
>
> Bob
> "Jeff Cochran" <jeff.nospam@zina.com> wrote in message
> news:4214daf6.30870068@msnews.microsoft.com...
>
>
>
| |
| Phil Agcaoili 2005-02-17, 5:53 pm |
| "David Wang [Msft]" wrote:
> No, I personally encourage you to heed Bob Christian's earlier advice and
> abandon your OWA 5.5 deployment plans.
>
> If you are asking "is HTTPS crackable" yet want to implement OWA5.5 for
> public Internet access by a kiosk, your security emphasis is seriously
> misplaced. Kiosk access will be the weak point for several reasons (as he
> listed) and will be a far easier target than HTTPS -- yet strangely, you are
> more concerned about HTTPS being cracked. Hackers go for low-hanging
> fruit -- easiest exploit to get the maximum damage is the first choice.
>
> Regarding your self-signed certificate -- of course the user will be warned
> about downloading and installing the self-signed certificate. If they are
> not, that would be a security vulnerability in the browser to allow a remote
> site to add trusted certificates. Additional problems:
> 1. You presume the user can even install the self-signed certificate on the
> kiosk (a kiosk that gives users such permissions is probably more dangerous
> to your data security)
> 2. You also presume that making users used to installing random certificates
> into the root store of their browser is a good security behavior.
>
> Really, the money you are saving is not worth the security risk you are
> taking on as well as the unsupported software you are investing in. Security
> of HTTPS infrastructure is simply the least of your concerns right now.
>
> --
> //David
My point was addressing his original request: "implementing OWA5.5 to be
accessible on the internet"
<seeker01@gmail.com> wrote in message
news:1108451618.516937.83460@c13g2000cwb.googlegroups.com...
> Dear all,
>
> The current project that I am working on is implementing OWA5.5 to be
> accessible on the internet.
>
> The architecture model that I am thinking of proposing to the
> management is to configure ISA 2000 server (sits at the internal
> network) to accept the HTTPS packet from PIX firewall; then forward
> HTTPS to OWA & CA server (which both sits at the internal network).
>
> This model will be tested because I am not an expert on ISA yet.
>
> But what concerns me more at the moment is "HTTPS crackable" by hackers
> and how that can happen?
>
> Thank you in advanced for your help.
>
> Regards,
> Seeker
There is a high likelihood that an OWA user will access their e-mail from a
potentially hostile pc/notebook/kiosk/cybercafe system.
I have been to a lot of customers and there is a lot of press about
keyloggers loaded at public places like Kinkos and other cyber cafes:
http://tech2.nytimes.com/mem/techno...75BC0A9659C8B63
My point also corroborates Bob Christian's earlier advice, but I'm adding
that if seeker is building out an OWA strategy in 2005, highly consider
integrating 2-factor authentication such as SecurID (because it defeats a
keylogger at a public terminal) and an SSL VPN (because you can Webarized
many of your intranet applications using 1 project--to secure OWA).
It's funny, there's a big push within Microsoft to integrate Federated
Identity Management solutions into Web-based applications and curious why
your reservation?
| |
| seeker01 2005-02-17, 8:49 pm |
| Can the Internet cafe user go ahead & install self-sign certificate if I the
only port I allow on PIX firewall is 443? My understanding is I can setup my
OWA server not to force user to install the self-signed certificate but the
communication channel is still port 443? Hope u can visualise what I meant
here because I cant express well using English.
"David Wang [Msft]" wrote:
> No, I personally encourage you to heed Bob Christian's earlier advice and
> abandon your OWA 5.5 deployment plans.
>
> If you are asking "is HTTPS crackable" yet want to implement OWA5.5 for
> public Internet access by a kiosk, your security emphasis is seriously
> misplaced. Kiosk access will be the weak point for several reasons (as he
> listed) and will be a far easier target than HTTPS -- yet strangely, you are
> more concerned about HTTPS being cracked. Hackers go for low-hanging
> fruit -- easiest exploit to get the maximum damage is the first choice.
>
> Regarding your self-signed certificate -- of course the user will be warned
> about downloading and installing the self-signed certificate. If they are
> not, that would be a security vulnerability in the browser to allow a remote
> site to add trusted certificates. Additional problems:
> 1. You presume the user can even install the self-signed certificate on the
> kiosk (a kiosk that gives users such permissions is probably more dangerous
> to your data security)
> 2. You also presume that making users used to installing random certificates
> into the root store of their browser is a good security behavior.
>
> Really, the money you are saving is not worth the security risk you are
> taking on as well as the unsupported software you are investing in. Security
> of HTTPS infrastructure is simply the least of your concerns right now.
>
> --
> //David
> IIS
> http://blogs.msdn.com/David.Wang
> This posting is provided "AS IS" with no warranties, and confers no rights.
> //
> "seeker01" <seeker01@discussions.microsoft.com> wrote in message
> news:6E9D6307-FFDF-44D0-A4FD-84AD5B52AC2A@microsoft.com...
> Hi all,
>
> For public workstation like Internet cafe, would the user be warned to
> download the self-signed certificate? Personally would you encourage me to
> force them to install the certificate on public workstation? Thank you once
> again.
>
> Seeker01
>
> "Bob Christian" wrote:
>
> 5.5
> actually
> having
> there,
> disk
> even
> Exchange
>
>
>
| |
| David Wang [Msft] 2005-02-18, 2:48 am |
| I believe I know what you are trying to do, but I do not think you
understand what my concerns are.
The port on the PIX firewall has nothing to do with an Internet cafe user's
ability to install self-sign certificate.
Let me clarify what is going on here:
1. As soon as you install a server certificate, configure a secure website
port, and enable that port to be accessible through the firewall, encrypted
communication works between appropriate client and server because they can
do the SSL handshake.
2. The reason you see the browser show a certificate popup is because your
server certificate is self signed, and the browser does NOT have that CA's
certificate on the kiosk, so it cannot trust its identity. Hence, popup.
3. Lack of trust does not mean that encrypted communication is not possible.
It simply means you cannot trust the identity receiving the other end of the
encrypted communication.
4. At which point, I must ask you: If you send content, perfectly encrypted
and unhackable, but you have no idea WHO or WHERE you sent the content to --
is the data still secured? I doubt it -- hacker could self sign their own
certificate and illegally trick your users into giving them the secured
content.
5. The only way to get the browser to stop popping up the certificate
question is for the browser to trust the signer of the server certificate.
This involves the browser user installing the server certificate into the
certificate store on the server and trusting it.
6. At which point, I must ask you: If you train your users to just accept
any certificate into their trusted store, is your data still secured? I
doubt it -- hacker could intercept and send their own certificate to your
users, so that they trust the hacker's server and *not* your own -- giving
them access to your secured content without you knowing about it.
7. Also, how are you sure that the Kiosk allows users to install
certificates?
Hopefully, you now see *SOME* of the problems associated with uncontrolled
Kiosk access. You can certainly setup OWA to use HTTPS and not require the
certificate installation, but for all practical purposes, you have achieved
no security for your email system. What you are trying to do is to ensure:
1. Data sent from server can only be read by the client users
2. Data sent from the client can only be acted by your Server
Your design does not assure that encrypted data is only acted upon by your
own Servers nor your own client users. Thus, even though SSL can encrypt the
traffic correctly, you have NO data security. Bad guy can still read and
intercept your encrypted traffic via classic man-in-the-middle attacks
because you cannot and did not secure the endpoints of the encrypted
connection.
If these risks are acceptable to you and your management, then go right on
ahead.
--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"seeker01" <seeker01@discussions.microsoft.com> wrote in message
news:D7160183-56D6-4747-8D79-41C6FE1F2D80@microsoft.com...
Can the Internet cafe user go ahead & install self-sign certificate if I the
only port I allow on PIX firewall is 443? My understanding is I can setup my
OWA server not to force user to install the self-signed certificate but the
communication channel is still port 443? Hope u can visualise what I meant
here because I cant express well using English.
"David Wang [Msft]" wrote:
> No, I personally encourage you to heed Bob Christian's earlier advice and
> abandon your OWA 5.5 deployment plans.
>
> If you are asking "is HTTPS crackable" yet want to implement OWA5.5 for
> public Internet access by a kiosk, your security emphasis is seriously
> misplaced. Kiosk access will be the weak point for several reasons (as he
> listed) and will be a far easier target than HTTPS -- yet strangely, you
are
> more concerned about HTTPS being cracked. Hackers go for low-hanging
> fruit -- easiest exploit to get the maximum damage is the first choice.
>
> Regarding your self-signed certificate -- of course the user will be
warned
> about downloading and installing the self-signed certificate. If they are
> not, that would be a security vulnerability in the browser to allow a
remote
> site to add trusted certificates. Additional problems:
> 1. You presume the user can even install the self-signed certificate on
the
> kiosk (a kiosk that gives users such permissions is probably more
dangerous
> to your data security)
> 2. You also presume that making users used to installing random
certificates
> into the root store of their browser is a good security behavior.
>
> Really, the money you are saving is not worth the security risk you are
> taking on as well as the unsupported software you are investing in.
Security
> of HTTPS infrastructure is simply the least of your concerns right now.
>
> --
> //David
> IIS
> http://blogs.msdn.com/David.Wang
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> //
> "seeker01" <seeker01@discussions.microsoft.com> wrote in message
> news:6E9D6307-FFDF-44D0-A4FD-84AD5B52AC2A@microsoft.com...
> Hi all,
>
> For public workstation like Internet cafe, would the user be warned to
> download the self-signed certificate? Personally would you encourage me to
> force them to install the certificate on public workstation? Thank you
once
> again.
>
> Seeker01
>
> "Bob Christian" wrote:
>
> 5.5
> actually
> having
> there,
Puppy[vbcol=seagreen]
machine[vbcol=seagreen]
item[vbcol=seagreen]
> disk
> even
> Exchange
OWA[vbcol=seagreen]
hackers[vbcol=seagreen]
>
>
>
| |
| David Wang [Msft] 2005-02-18, 7:49 am |
| Weird, I sent a reply 5 hours ago and it did not show up here. Anyways...
I am happy to see your detailed responses to the original question.
I am reserved by the user's choice of implementation and line of questioning
(willing to question HTTPS protocal security prior to questioning
OWA55/Kiosk security), not necessary Microsoft's strategy. I do not think
OWA55 is Federated, yes?
I think we are all just violently agreeing with each other. :-)
--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//
"Phil Agcaoili" <PhilAgcaoili@discussions.microsoft.com> wrote in message
news:5729FB7E-8CB6-44E8-A584-89E5AAB1B034@microsoft.com...
"David Wang [Msft]" wrote:
> No, I personally encourage you to heed Bob Christian's earlier advice and
> abandon your OWA 5.5 deployment plans.
>
> If you are asking "is HTTPS crackable" yet want to implement OWA5.5 for
> public Internet access by a kiosk, your security emphasis is seriously
> misplaced. Kiosk access will be the weak point for several reasons (as he
> listed) and will be a far easier target than HTTPS -- yet strangely, you
are
> more concerned about HTTPS being cracked. Hackers go for low-hanging
> fruit -- easiest exploit to get the maximum damage is the first choice.
>
> Regarding your self-signed certificate -- of course the user will be
warned
> about downloading and installing the self-signed certificate. If they are
> not, that would be a security vulnerability in the browser to allow a
remote
> site to add trusted certificates. Additional problems:
> 1. You presume the user can even install the self-signed certificate on
the
> kiosk (a kiosk that gives users such permissions is probably more
dangerous
> to your data security)
> 2. You also presume that making users used to installing random
certificates
> into the root store of their browser is a good security behavior.
>
> Really, the money you are saving is not worth the security risk you are
> taking on as well as the unsupported software you are investing in.
Security
> of HTTPS infrastructure is simply the least of your concerns right now.
>
> --
> //David
My point was addressing his original request: "implementing OWA5.5 to be
accessible on the internet"
<seeker01@gmail.com> wrote in message
news:1108451618.516937.83460@c13g2000cwb.googlegroups.com...
> Dear all,
>
> The current project that I am working on is implementing OWA5.5 to be
> accessible on the internet.
>
> The architecture model that I am thinking of proposing to the
> management is to configure ISA 2000 server (sits at the internal
> network) to accept the HTTPS packet from PIX firewall; then forward
> HTTPS to OWA & CA server (which both sits at the internal network).
>
> This model will be tested because I am not an expert on ISA yet.
>
> But what concerns me more at the moment is "HTTPS crackable" by hackers
> and how that can happen?
>
> Thank you in advanced for your help.
>
> Regards,
> Seeker
There is a high likelihood that an OWA user will access their e-mail from a
potentially hostile pc/notebook/kiosk/cybercafe system.
I have been to a lot of customers and there is a lot of press about
keyloggers loaded at public places like Kinkos and other cyber cafes:
http://tech2.nytimes.com/mem/techno...75BC0A9659C8B63
My point also corroborates Bob Christian's earlier advice, but I'm adding
that if seeker is building out an OWA strategy in 2005, highly consider
integrating 2-factor authentication such as SecurID (because it defeats a
keylogger at a public terminal) and an SSL VPN (because you can Webarized
many of your intranet applications using 1 project--to secure OWA).
It's funny, there's a big push within Microsoft to integrate Federated
Identity Management solutions into Web-based applications and curious why
your reservation?
|
|
|
|
|