On Tue May 19 2009, Dave Thompson wrote:
> > From: owner-openssl-us...@openssl.org On Behalf Of Ger Hobbelt
> > Sent: Monday, 18 May, 2009 13:04
> - - - snip - - -
> >
> > c) the 'guaranteed delivery' I mentioned before: VMS offers
> > this as a message-based protocol, but you can easily convert
João Távora wrote:
> Given a NDA forbids me from giving you more details let me give you
> an analogy with postal services: I assume you know of postal services
> where you can get a delivery receipt. you can get a receipt that the
> recipient was notified, if the postman gets shot along the way
> From: owner-openssl-us...@openssl.org On Behalf Of Ger Hobbelt
> Sent: Monday, 18 May, 2009 13:04
> Quite a bit has been covered in the answers so far, but
> there's still some material left.
Apparently. Much that I agree with, or is redundant, snipped.
> Considering the 'guaranteed delivery'
> The equivalent of application acknowledgment would be the
> *letter* saying to the person "once you read this, return
> the attached form." Then you need the application has
> read the message and done something about it.
Certainly. But I don't need this. I just need registered mail, that is
be
On Tue, May 19, 2009 at 10:53:05AM +0200, João Távora wrote:
> Given a NDA forbids me from giving you more details let me give you
> an analogy with postal services: I assume you know of postal services
> where you can get a delivery receipt. you can get a receipt that the
> recipient was notified
Given a NDA forbids me from giving you more details let me give you
an analogy with postal services: I assume you know of postal services
where you can get a delivery receipt. you can get a receipt that the
recipient was notified, if the postman gets shot along the way, the
postal service will sen
Joao Tavora wrote:
> Certainly! I never said it did. TCP ensures delivery to the host,
> not the application. But it does ensure it up to the host, or if
> that cant be achieved the peer host is appropriately notified.
Right, none of which has any application-level consequences. These are all
in
David,
I think we're drifting a little bit from my original question here. I
certainlly don't mean to imply that there's anything wrong with SSL or
the OpenSSL's implementation, I just want to discover if it does what
I want.
TCP specifically does *not* communicate ACKs up to the applic
On Mon, May 18, 2009, Kyle Hamilton wrote:
>
> Both of which are described as "hard problems". It's not known
> whether they qualify as NP-complete, but they definitely qualify as
> NP-hard (NP meaning 'nonpolynomial time', or 'the amount of time
> required to do it is logarithmic with how much
2009/5/18 Nikos Balkanas :
> It would require a lot of effort, but a transparent proxy, can rewrite IP
> source headers, sequence numbers, ACKs and if it has followed all algos and
> key exchanges, even regenerate those. HMAC is nothing more than a glorified
> CRC encoded with some secret exchanged
On Mon, May 18, 2009 at 6:26 PM, David Schwartz wrote:
[...]
Whoops. I was writing my response while David's made it already
across. His is shorter and saying exactly the same.
ACKs are not important. There's message, there's stream and the
security breach. The latter does not happen due to any
On Sun, May 17, 2009 at 8:22 PM, João Távora wrote:
> Maybe I didn't really fully explain myself, the problem is not really
> ensuring secrecy and integrity, it's ensuring delivery.
[...]
> In this case the attacker would have tampered with the delivery assurance of
> TCP but none of the sides wou
João wrote:
> > TCP does not provide "delivery assurance". If the application needs
> > to know
> > the data got through, it must use application-level
> > ackwowledgements. SSL
> > does not change this and provides the same set of guarantees and
> > assurances
> > TCP does.
> I'm sorry to disag
* Nikos Balkanas wrote on Mon, May 18, 2009 at 15:29 +0300:
> Wikipedia is right in principle, but doesn't cover the case of TCP
> hijacking.
I think this is out of scope,
TCP is said to be reliable, not neccesarily secure.
oki,
Steffen
--[ end of message ]-
some secret exchanged at the start. If anyone captures that
secret can regenerate all MACs.
Transparent proxies and gateways are always a concern in security,
BR,
Nikos
- Original Message -
From: "Andrey Koltsov"
To:
Sent: Monday, May 18, 2009 8:59 AM
Subject: Re: SSL
-
> What this article says is this: if you *received* data from TCP
> connection it will be "without duplication or losing data". It doesn't
> say: if you *send* data it will be received correctly by other host.
> It's impossible to garantee.
>
> --
> Andrey Koltsov
With TCP you basically don't k
João Távora пишет:
TCP does not provide "delivery assurance". If the application needs
to know
the data got through, it must use application-level ackwowledgements.
SSL
does not change this and provides the same set of guarantees and
assurances
TCP does.
I'm sorry to disagree but TCP, unli
TCP allows for hijacking -- but the fact that the SSL/TLS layer uses
secret, ever-changing HMACs means that an attacker cannot pass any
data to the hijacked session without it being detected and a protocol
error resulting. (Much less the encryption key for all but NULL
ciphers.)
TCP guarantees de
TCP does not provide "delivery assurance". If the application needs
to know
the data got through, it must use application-level
ackwowledgements. SSL
does not change this and provides the same set of guarantees and
assurances
TCP does.
I'm sorry to disagree but TCP, unlike UDP, does prov
João wrote:
> Hi
>
> I'm glad for your negative answer and that's also what I suspect :-)
>
> ... but I didn't really understand why.
>
> Maybe I didn't really fully explain myself, the problem is not really
> ensuring secrecy and integrity, it's ensuring delivery.
No protocol can ensure the oth
Hi
I'm glad for your negative answer and that's also what I suspect :-)
... but I didn't really understand why.
Maybe I didn't really fully explain myself, the problem is not really
ensuring secrecy and integrity, it's ensuring delivery.
As I understand it this is normally done with TCP ACK
No.
Part of the SSL/TLS handshake protocol is the definition of what the
content of the message should include -- i.e., the HMAC. If it
doesn't exist or is different from what it's supposed to be, the side
that failed to validate it sends a decryption_error fatal alert and
closes the connection.
Hi,
I've got a newbie question about a possible SSL/OpenSSL
Consider two machines A and B and a man-in-the-middle, Z, who can
snoop traffic.
A and B exchange certificates securely, i.e. Z lets the SSL handshake
through. Therefore A sends a first application-data message to B.
Z cannot re
23 matches
Mail list logo
