|
Posted by TwistedPair on September 23, 2006, 8:06 pm
Please log in for more thread options
All,
Hopefully this isn't a completely ridiculous question, but with IPSec when
two machines negotiate a connection, they can be configured to initially use
Kerberos, Certificates, or shared key authentication (if I understand
correctly). How much more secure are certificates than shared secrets?
Wouldn't it be possible to use a Man in the Middle (MITM) attack by simply
replaying a cert the same way you would a shared secret?
-P
|
|
Posted by S. Pidgorny on September 24, 2006, 9:02 am
Please log in for more thread options
Shared secrets is something that you can share without access to the systems
in question - knowledge only is required.
To compromise access using "soft" certificates, you usually need physical
access to the hardware and/or admin rights.
If certificates are implemented in hardware (smart card/HSM/TPM), you cannot
copy/clone the access credential. This is the safest.
Man in the middle attack won't work with either. IPsec is using proper
cryptographic handshake, thus never transmitting the credential/creating
opportunity for replay.
--
Svyatoslav Pidgorny, MS MVP - Security, MCSE
-= F1 is the key =-
> All,
> Hopefully this isn't a completely ridiculous question, but with IPSec when
> two machines negotiate a connection, they can be configured to initially
> use Kerberos, Certificates, or shared key authentication (if I understand
> correctly). How much more secure are certificates than shared secrets?
> Wouldn't it be possible to use a Man in the Middle (MITM) attack by simply
> replaying a cert the same way you would a shared secret?
>
> -P
>
|
|
Posted by Karl Levinson, mvp on September 24, 2006, 9:19 am
Please log in for more thread options
> All,
> Hopefully this isn't a completely ridiculous question, but with IPSec when
> two machines negotiate a connection, they can be configured to initially
> use Kerberos, Certificates, or shared key authentication (if I understand
> correctly). How much more secure are certificates than shared secrets?
> Wouldn't it be possible to use a Man in the Middle (MITM) attack by simply
> replaying a cert the same way you would a shared secret?
Certificates are generally considered more secure than shared secret.
Often, the same shared secret is deployed across multiple system, which is
sort of like a shared password that many people know (in this case,
administrators of those devices). With shared secret, you often don't have
the ability to globally change the "password" at regular intervals or when
an administrator leaves the organization, which is generally considered
important to security.
Both certificates and shared secrets are equally vulnerable to man in the
middle attacks, which are fairly easy to mount with SSL and SSH. With
IPSec, however, the risk of man in the middle attacks is mitigated.
--
kind regards,
Karl Levinson, MS MVP
Security FAQ site:
http://securityadmin.info/faq.asp
|
|
Posted by TwistedPair on September 24, 2006, 8:19 am
Please log in for more thread options Thank you both for your explanations. Quick question below:
>
>> All,
>> Hopefully this isn't a completely ridiculous question, but with IPSec
>> when
>> two machines negotiate a connection, they can be configured to initially
>> use Kerberos, Certificates, or shared key authentication (if I understand
>> correctly). How much more secure are certificates than shared secrets?
>> Wouldn't it be possible to use a Man in the Middle (MITM) attack by
>> simply
>> replaying a cert the same way you would a shared secret?
>
> Certificates are generally considered more secure than shared secret.
> Often, the same shared secret is deployed across multiple system, which is
> sort of like a shared password that many people know (in this case,
> administrators of those devices). With shared secret, you often don't
> have
> the ability to globally change the "password" at regular intervals or when
> an administrator leaves the organization, which is generally considered
> important to security.
>
> Both certificates and shared secrets are equally vulnerable to man in the
> middle attacks, which are fairly easy to mount with SSL and SSH. With
> IPSec, however, the risk of man in the middle attacks is mitigated.
Unless I miss my guess here, this is because with SSL the first time a
client establishes a connection to the server, the certificate is
transmitted to the client. A MITM attack could intercept this certificate
and use it to decrypt the session once it's been established. With IPSec
however, the certificate is never transmitted because it needs to be
manually installed on the client machine. Does this sound correct?
-P
>
> --
> kind regards,
> Karl Levinson, MS MVP
> Security FAQ site:
> http://securityadmin.info/faq.asp
>
>
>
begin 666 Re_ IPSec certs vs shared secret.nws
M1G)O;3H@(E,N(%!I9&=O<FYY(#Q-5E ^(B \<VQA=FEC:W! >6%H;V\N8V]M
M/@T*4F5F97)E;F-E<SH@/$\W;317,3(S1TA!+C4P.3) 5$LR35-&5$Y'4# T
M+G!H>"YG8FP^#0I3=6)J96-T.B!293H@25!396,@8V5R=',@=G,@<VAA<F5D
M('-E8W)E= T*1&%T93H@4W5N+" R-"!397 @,C P-B R,SHP,CHT-R K,3 P
M, T*3&EN97,Z(#(Y#0I8+5!R:6]R:71Y.B S#0I8+4U336%I;"U0<FEO<FET
M>3H@3F]R;6%L#0I8+4YE=W-R96%D97(Z($UI8W)O<V]F="!/=71L;V]K($5X
M<')E<W,@-BXP,"XS-SDP+C(V-C,-"E@M36EM94],13H@4')O9'5C960@0GD@
M36EC<F]S;V9T($UI;65/3$4@5C8N,# N,S<Y,"XR-S4W#0I8+5)&0S(V-#8Z
M($9O<FUA=#U&;&]W960[(%)E<W!O;G-E#0I-97-S86=E+4E$.B V-!=#EM
M.3-'2$$N,3 V.$!42S)-4T943D=0,#4N<&AX+F=B;#X-"DYE=W-G<F]U<',Z
M(&UI8W)O<V]F="YP=6)L:6,N=VEN9&]W<RYS97)V97(N<V5C=7)I='D-"DY.
M5% M4&]S=&EN9RU(;W-T.B!P<' Q.#$M-3$N;&YS,BYM96PT+FEN=&5R;F]D
M92YO;BYN970@-3DN,38W+C$X,2XU,0T*4&%T:#H@5$LR35-&5$Y'4# Q+G!H
M>"YG8FPA5$LR35-&5$Y'4# U+G!H>"YG8FP-"EAR968Z(%1+,DU31E1.1U P
M,2YP:'@N9V)L(&UI8W)O<V]F="YP=6)L:6,N=VEN9&]W<RYS97)V97(N<V5C
M=7)I='DZ,30S.#0-"@T*4VAA<F5D('-E8W)E=',@:7,@<V]M971H:6YG('1H
M870@>6]U(&-A;B!S:&%R92!W:71H;W5T(&%C8V5S<R!T;R!T:&4@<WES=&5M
M<R -"FEN('%U97-T:6]N("T@:VYO=VQE9&=E(&]N;'D@:7,@<F5Q=6ER960N
M#0I4;R!C;VUP<F]M:7-E(&%C8V5S<R!U<VEN9R B<V]F="(@8V5R=&EF:6-A
M=&5S+"!Y;W4@=7-U86QL>2 @;F5E9"!P:'ES:6-A;" -"F%C8V5S<R!T;R!T
M:&4@:&%R9'=A<F4@86YD+V]R(&%D;6EN(')I9VAT<RX-"DEF(&-E<G1I9FEC
M871E<R!A<F4@:6UP;&5M96YT960@:6X@:&%R9'=A<F4@*'-M87)T(&-A<F0O
M2%--+U1032DL('EO=2!C86YN;W0@#0IC;W!Y+V-L;VYE('1H92!A8V-E<W,@
M8W)E9&5N=&EA;"X@5&AI<R!I<R!T:&4@<V%F97-T+@T*#0I-86X@:6X@=&AE
M(&UI9&1L92!A='1A8VL@=V]N)W0@=V]R:R!W:71H(&5I=&AE<BX@25!S96,@
M:7,@=7-I;F<@<')O<&5R( T*8W)Y<'1O9W)A<&AI8R!H86YD<VAA:V4L('1H
M=7,@;F5V97(@=')A;G-M:71T:6YG('1H92!C<F5D96YT:6%L+V-R96%T:6YG
M( T*;W!P;W)T=6YI='D@9F]R(')E<&QA>2X-"@T*+2T@#0I3=GEA=&]S;&%V
M=&AE(&ME>2 ]+0T*#0HB5'=I<W1E9%!A:7(B(#QT=VES=&5D<&%I<D!M86EL
M+F-O;3X@=W)O=&4@:6X@;65S<V%G92 -"FYE=W,Z3S=M-%<Q,C-'2$$N-3 Y
M,D!42S)-4T943D=0,#0N<&AX+F=B;"XN+@T*/B!!;&PL#0H^($AO<&5F=6QL
M>2!T:&ES(&ES;B=T(&$@8V]M<&QE=&5L>2!R:61I8W5L;W5S('%U97-T:6]N
M+"!B=70@=VET:"!)4%-E8R!W:&5N( T*/B!T=V\@;6%C:&EN97,@;F5G;W1I
M871E(&$@8V]N;F5C=&EO;BP@=&AE>2!C86X@8F4@8V]N9FEG=7)E9"!T;R!I
M;FET:6%L;'D@#0H^('5S92!+97)B97)O<RP@0V5R=&EF:6-A=&5S+"!O<B!S
M:&%R960@:V5Y(&%U=&AE;G1I8V%T:6]N("AI9B!)('5N9&5R<W1A;F0@#0H^
M(&-O<G)E8W1L>2DN("!(;W<@;75C:"!M;W)E('-E8W5R92!A<F4@8V5R=&EF
M:6-A=&5S('1H86X@<VAA<F5D('-E8W)E=',_( T*/B!7;W5L9&XG="!I="!B
M92!P;W-S:6)L92!T;R!U<V4@82!-86X@:6X@=&AE($UI9&1L92 H34E432D@
M871T86-K(&)Y('-I;7!L>2 -"CX@<F5P;&%Y:6YG(&$@8V5R="!T:&4@<V%M
M92!W87D@>6]U('=O=6QD(&$@<VAA<F5D('-E8W)E=#\-"CX-"CX@+5 -"CX@
$#0H-"@``
`
end
|
|
Posted by Karl Levinson, mvp on September 24, 2006, 1:32 pm
Please log in for more thread options
>> Both certificates and shared secrets are equally vulnerable to man in the
>> middle attacks, which are fairly easy to mount with SSL and SSH. With
>> IPSec, however, the risk of man in the middle attacks is mitigated.
>
> Unless I miss my guess here, this is because with SSL the first time a
> client establishes a connection to the server, the certificate is
> transmitted to the client. A MITM attack could intercept this certificate
> and use it to decrypt the session once it's been established. With IPSec
> however, the certificate is never transmitted because it needs to be
> manually installed on the client machine. Does this sound correct?
Well, I don't believe SSL certificates are exactly exchanged, but session
keys. A MITM can observe and influence the key exchange in a few ways. A
MITM who observes the initial session negotiation can pretend to be the
server and establish encrypted SSL sessions with both ends. If SSL 2.0 is
enabled on the client [which is the default on all versions of Internet
Explorer today], a MITM could also spoof the server response during the
negotiation of which protocol to use, and then attack weaknesses in SSL 2.0,
do a brute force of the session keys, send spoofed requests to one side to
gather pairs of unencrypted and encrypted data for comparison and key
analysis, etc. SSL 2.0 negotiates encryption protocols in unencrypted clear
text that is not protected against modification en route.
With many SSL and SSH implementations, humans can click a button to allow an
encrypted session to continue when the SSL certificate fails to check out.
This wouldn't happen with IPSec between two routers, for example.
--
kind regards,
Karl Levinson, MS MVP
Security FAQ site:
http://securityadmin.info/faq.asp
|
| Similar Threads | Posted | | AD CS 2008 - issuing IPSEC certs from a stand-alone CA: | January 31, 2008, 3:17 pm |
| Shared key for 3des IPSEC encryption | September 18, 2006, 6:51 am |
| Child domain laptops autoenrolling user certs but not computer certs | May 21, 2008, 4:19 pm |
| Problem with Machine Certs being used as User Certs | June 15, 2005, 7:06 am |
| Self-signed certs for FTP | October 10, 2006, 7:07 pm |
| CA configuration to publish certs in AD | October 2, 2006, 9:42 am |
| GPO for trusted root CA certs | November 7, 2006, 8:12 am |
| Certs in non-domain environment: | January 24, 2008, 12:51 pm |
| Auto-renewing certs w/ VPN clients | February 15, 2006, 9:44 am |
| Issuer Statement does not appear in user certs | October 4, 2006, 4:52 pm |
|
XML Sitemap