Hi there,
What's the difference between implementing pure SSL vs. SSL over tcp/
ip? what's the advantage/disadvantage when comparing them?
Can I say that on top of old tcp/ip application, we can add SSL on top
of it for less effort, and for new application we go ahead to use pure
SSL?
Thanks and regards,
Jackie
> What's the difference between implementing pure SSL vs. SSL over tcp/
> ip? what's the advantage/disadvantage when comparing them?
>
> Can I say that on top of old tcp/ip application, we can add SSL on top
> of it for less effort, and for new application we go ahead to use pure
> SSL?
There is some misconception here. SSL is operating in another layer
than TCP. You can place anything under SSL, be it TCP/IP, UDP/IP or
even something entirely different than IP.
Regards,
Ertugrul Söylemez.
--=20
=46rom the fact that this CGI program has been written in Haskell, it
follows naturally that this CGI program is perfectly secure.
Jackie
> What's the difference between implementing pure SSL vs. SSL over tcp/
> ip?
SSL is now TLS, and it's implemented using a reliable transport protocol
only (usually TCP), see RFC 4346. There is no such thing like "pure
SSL".
Yours,
VB.
--
"Terror eignet sich mehr als irgendeine andere militärische Strategie dazu,
die Bevölkerung zu manipulieren."
(Dr. Daniele Ganser, 2005)
Ertugrul Soeylemez
> You can place anything under SSL, be it TCP/IP, UDP/IP or
> even something entirely different than IP.
That's not completely true. RFC 4346 says in it's introduction already:
| At the lowest level, layered on top of some reliable
| transport protocol (e.g., TCP[TCP]), is the TLS Record Protocol.
This implies, that you cannot use UDP for TLS, because UDP is not
reliable.
Yours,
VB.
--
"Terror eignet sich mehr als irgendeine andere militärische Strategie dazu,
die Bevölkerung zu manipulieren."
(Dr. Daniele Ganser, 2005)
In article <1176838394.505611.79460@e65g2000hsc.googlegroups.com>, Jackie wrote:
>Hi there,
>
>What's the difference between implementing pure SSL vs. SSL over tcp/
>ip? what's the advantage/disadvantage when comparing them?
>
>Can I say that on top of old tcp/ip application, we can add SSL on top
>of it for less effort, and for new application we go ahead to use pure
>SSL?
>
>
Um, wha? That makes no sense whatsoever. SSL is not an transport
protocol, it is an encryption protocol. You can't send things with
"pure SSL", whatever that's supposed to mean.
--
Christopher Mattern
NOTICE
Thank you for noticing this new notice
Your noticing it has been noted
And will be reported to the authorities
Volker Birk
> > You can place anything under SSL, be it TCP/IP, UDP/IP or even
> > something entirely different than IP.
>
> That's not completely true. RFC 4346 says in it's introduction
> already:
>
> | At the lowest level, layered on top of some reliable transport
> | protocol (e.g., TCP[TCP]), is the TLS Record Protocol.
>
> This implies, that you cannot use UDP for TLS, because UDP is not
> reliable.
Firstly we're talking about SSL, not TLS. Secondly, we have a free
layer 5, where we can make unreliable transport protocols reliable.
Regards,
Ertugrul Söylemez.
--=20
=46rom the fact that this CGI program has been written in Haskell, it
follows naturally that this CGI program is perfectly secure.
Volker Birk
> > What's the difference between implementing pure SSL vs. SSL over
> > tcp/ ip?
>
> SSL is now TLS, and it's implemented using a reliable transport
> protocol only (usually TCP), see RFC 4346. There is no such thing like
> "pure SSL".
TLS is a new protocol, for which it currently happens to be that it uses
SSLv3 underlyingly for the actual communication. But the specification
leaves this open, so that you can use almost any protocol. TLS is
supposed to abstract away the specifics of certain protocols, so that we
get more interoperability. For example, TLS can be embedded into a
clear-text protocol as an extension, which can be activated inside of
the session. SSL cannot be used that way.
Regards,
Ertugrul Söylemez.
--=20
=46rom the fact that this CGI program has been written in Haskell, it
follows naturally that this CGI program is perfectly secure.
Volker Birk wrote:
> Jackie
>> What's the difference between implementing pure SSL vs. SSL over tcp/
>> ip?
>
> SSL is now TLS,
No. TLS is based on SSL v3, but is different from it. Only Netscape insists
on calling it SSL v3.1.
> ...and it's implemented using a reliable transport protocol
> only (usually TCP), see RFC 4346. There is no such thing like "pure
> SSL".
There is "TLS over UDP", or DTLS:
http://www.ietf.org/rfc/rfc4347.txt
-- Lassi
Ertugrul Soeylemez
> > This implies, that you cannot use UDP for TLS, because UDP is not
> > reliable.
> Firstly we're talking about SSL, not TLS.
That doesn't matter.
> Secondly, we have a free
> layer 5, where we can make unreliable transport protocols reliable.
You're using a very strange method to agree with me.
Yours,
VB.
--
"Terror eignet sich mehr als irgendeine andere militärische Strategie dazu,
die Bevölkerung zu manipulieren."
(Dr. Daniele Ganser, 2005)
"Ertugrul Soeylemez"
news:f09n1l$gjs$01$1@news.t-online.com...
Firstly we're talking about SSL, not TLS. Secondly, we have a free
layer 5, where we can make unreliable transport protocols reliable.
Sounds like you totally miss the meaning of "reliable" in the context of the
standard.
...
"xpyttl"
> Firstly we're talking about SSL, not TLS. Secondly, we have a free
> layer 5, where we can make unreliable transport protocols reliable.
>
> Sounds like you totally miss the meaning of "reliable" in the context of the
> standard.
we were called into consult with this small client/server startup that
wanted to do payment transactions on their server ... and they had this
technology called SSL they wanted to use. we had to do a technology
end-to-end audit ... as well as an end-to-end business audit ... i.e.
all the businesses that might be associated with webservers, things
called digital certificates (and how these things called certificaton
authorities actually did their business), etc. misc. past posts on
ssl domain name digital certificates
http://www.garlic.com/~lynn/subpubkey.html#sslcert
we did have approval/sign-off on the webserver to payment gateway
part of the implementation ... misc. past posts about payment gateway
http://www.garlic.com/~lynn/subpubkey.html#gateway
and had to specify some additional operations for SSL ... like mutual
authentication ... which didn't exist at the time. both http and https
was implemented running over TCP ... supposedly a "reliable" protocol.
in part because we had done ha/cmp product
http://www.garlic.com/~lynn/subtopic.html#hacmp
we had setup the payment gateway as a continuous operation with multiple
different physical connections into multiple different carefully
selected ISPs ... that were at different places in the internet backbone
(and also have since claimed it was the original SOA).
in the midst of doing all this ... the internet governance transitioned
from anarchy routing (i.e. ROUTED and such advertisements) to
hierarchical routing (part of the problem was anarchy routing was
exceeded available memory space in backbone routers ... and
transitioning to hierarchical routing saved significant memory). As a
result, it was no longer possible to dynamically advertise routes as
countermeasure to various failures and/or partitioning in the internet
(or even ISP taking hardware down on sundays for maintenance). So the
only alternative left was (domain name) multiple-A record support and
the "client" (setting up the connection) running thru all the advertised
A-records until it found one that got thru.
At the time, we got several howls from individuals claiming that using
straight-forward TCP connects provided for "reliable transport" ... but
that was only true once the connection was made. It their wasn't a
specific path that was up-and-running ... it was still possible for the
initial TCP connection to fail (we came up with the observation that if
it wasn't in the steven's tcp/ip book used in undergraduate course, they
didn't know it existed). Once the TCP connection was made to the
appropriate port ... then http/https could start their part of the
process.
The explanation of multiple-A records was met with response that it was
"way too advanced" (even when presented with telnet example code from
4.3 Tahoe) ... however, since we had sign-off/approval for the server to
payment gateway implementation ... it had to be implemented. However, it
took another year to get the client/browser to implement it for the
client to server operation.
An example was an early, large web merchant that would advertise
products in commercials that ran in sunday afternoon football. However,
one of their ISPs had standard operations that they took routers down on
sunday for maintenance. As a result ... all browsers that were routing
in through that ISP path would be unable to connect during half-time
(which was prime activity for them) ... even though there were alternate
paths that were available for connection.
This was in the period that ipsec was attempting to take over the world
with end-to-end (network) encryption. I've claimed that both SSL and VPN
got a lot of uptake in that period because of the difficulty that ipsec
was having in getting new kernel space tcp/ip stack code deployed. About
the same time that SSL was starting to be used ... a friend of ours that
we had worked with since late 70s ... introduced (router/gateway based)
VPN in the gateway committee meeting at the IETF san jose meeting. My
observation was that it ruffled some feathers in the ipsec operation
.... until they came up with the label "lightweight ipsec" for VPNs
(which met that everybody else could call what they were doing
"heavyweight ipsec").
A corporation with hundreds/thousands of machines containing their own
kernels and tcp/ip protocol stack ... didn't have to be updated.
Individuals could just load a new browser application ... and voila
.... all of a sudden they had "end-to-end" (application layer) encryption
(it was similarly simple for end-users/consumers with their own home
machine ... where the kernel had been preloaded by the PC vendor).
from our rfc index
http://www.garlic.com/~lynn/rfcietff.htm
click on "Term (term->RFC#)" in "RFCs listed by" section. Then click on
"TLS" in the "acronym fastpath" section ... i.e.
transport layer security (TLS )
see also encryption , security
4785 4762 4681 4680 4642 4572 4513 4507 4492 4366 4347 4346 4279 4261
4217 4162 4132 3943 3788 3749 3734 3546 3436 3268 3207 2847 2830 2818
2817 2716 2712 2595 2487 2246
clicking on the RFC number brings up the RFC summary in the lower
frame; clicking on the ".txt=nnn" field in the RFC summary retrieves
the actual RFC.
similarly:
transmission control protocol (TCP )
see also connection network protocol
4828 4808 4782 4727 4654 4653 4614 4413 4404 4342 4341 4278 4163 4145
4138 4022 4015 3822 3821 3782 3742 3734 3708 3649 3562 3522 3517 3481
3465 3449 3448 3430 3390 3360 3293 3081 3042 2988 2923 2883 2873 2861
2760 2582 2581 2525 2488 2452 2416 2415 2414 2398 2385 2151 2147 2140
2126 2018 2012 2001 1859 1792 1791 1739 1693 1644 1613 1470 1379 1347
1337 1323 1273 1263 1213 1195 1185 1180 1158 1156 1155 1147 1146 1145
1144 1110 1106 1095 1086 1085 1078 1072 1066 1065 1025 1006 1002 1001
983 964 962 896 889 879 872 848 846 845 843 842 839 838 837 836 835 834
833 832 817 816 814 813 801 794 793 773 761 721 700 675
for other topic drift ... while tcp/ip was the technology basis
for the modern internet ... we claim that the NSFNET backbone was
the operational basis for the modern internet ... misc. past posts
http://www.garlic.com/~lynn/subnetwork.html#nsfnet