| Trolltech Home | Qt-interest Home | Recent Threads | All Threads | Author | Date | |
| All threads index page 4 | |
The QSslsocket documentation shows the encrypted() signal being connected to a ready() slot. However, I can't find any other reference to the ready() slot in Assistant. Can someone explain what's going on ? -- [ signature omitted ]
Stephen Collyer wrote: >The QSslsocket documentation shows the encrypted() signal >being connected to a ready() slot. However, I can't find >any other reference to the ready() slot in Assistant. > >Can someone explain what's going on ? That slot is in your class. -- [ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.
Thiago Macieira wrote: > Stephen Collyer wrote: >> The QSslsocket documentation shows the encrypted() signal >> being connected to a ready() slot. However, I can't find >> any other reference to the ready() slot in Assistant. >> >> Can someone explain what's going on ? > > That slot is in your class. Right. However, that raises the question of what one is supposed to do in that slot. It's not clear to me, for example, what is the relationship between the emission of encrypted() and, say, readyRead(). Is there some particular action that the class should take when encrypted() is emitted, and before a slot connected to readyRead() should execute ? -- [ signature omitted ]
You can connect the signal "readyRead()" to the appropriate slot (for exemple your own "process()" slot) in the slot connected with the "encrypted()" signal (for exemple your own "enableConnection()" ). Thus, the data will be processed in your "process()" slot, only after the connection is encrypted. On 5/17/08, Stephen Collyer <scollyer@xxxxxxxxxxxxxxxx> wrote: > > Thiago Macieira wrote: > > Stephen Collyer wrote: > >> The QSslsocket documentation shows the encrypted() signal > >> being connected to a ready() slot. However, I can't find > >> any other reference to the ready() slot in Assistant. > >> > >> Can someone explain what's going on ? > > > > That slot is in your class. > > > Right. However, that raises the question of what one > is supposed to do in that slot. It's not clear to me, > for example, what is the relationship between the > emission of encrypted() and, say, readyRead(). > > Is there some particular action that the class should > take when encrypted() is emitted, and before a > slot connected to readyRead() should execute ? > > > -- > Regards > > Steve Collyer > Netspinner Ltd > > -- > To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with > "unsubscribe" in the subject or the body. > List archive and information: http://lists.trolltech.com/qt-interest/ > >
David Keller wrote: > You can connect the signal "readyRead()" to the appropriate slot > (for exemple your own "process()" slot) in the slot connected with the > "encrypted()" signal (for exemple your own "enableConnection()" ). > Thus, the data will be processed in your "process()" slot, only after the > connection is encrypted. I'm not entirely sure what you're suggesting or why. It's not clear to me what are the semantics and relative timing of the encrypted() and readyRead() signals. For example: 1. Can readyRead() by emitted before encrypted() ? If so what action should be taken in readyRead() if this occurs ? 2. Is there any specific action that must be taken when encrypted() is emitted, or is it merely a convenience signal ? -- [ signature omitted ]
On Monday 19 May 2008 09:15:30 Stephen Collyer wrote: > David Keller wrote: > > You can connect the signal "readyRead()" to the appropriate slot > > (for exemple your own "process()" slot) in the slot connected with the > > "encrypted()" signal (for exemple your own "enableConnection()" ). > > Thus, the data will be processed in your "process()" slot, only after the > > connection is encrypted. > > I'm not entirely sure what you're suggesting or why. > > It's not clear to me what are the semantics and relative > timing of the encrypted() and readyRead() signals. For > example: > > 1. Can readyRead() by emitted before encrypted() ? > If so what action should be taken in readyRead() if this occurs ? Yes, it can happen. If you get to readyRead() before encrypted(), it means the data is unencrypted or it's the encryption handshake. This should not happen if you use connectToHostEncrypted(). In general, this is useful in protocols that start out in cleartext and initiate encryption after a command (like STARTTLS in SMTP). Since you need to handle the cleartext protocol handshake and the very likely result of sending the STARTTLS command, the readyRead() signal will be emitted before encrypted(). > 2. Is there any specific action that must be taken when > encrypted() is emitted, or is it merely a convenience > signal ? You tell us. What does your application do when the connection becomes encrypted? This is what you've been failing to understand: the ready() slot you're referring to is *your* slot. It's when you do something. What it is that you do is entirely up to you. If you are implementing an HTTP stack, you'll want to send the GET or POST command. If you're implementing a protocol for which the server will send a welcome message first, you should be waiting for readyRead(). -- [ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.
Thiago Macieira wrote: >> 1. Can readyRead() by emitted before encrypted() ? >> If so what action should be taken in readyRead() if this occurs ? > > Yes, it can happen. If you get to readyRead() before encrypted(), it means the > data is unencrypted or it's the encryption handshake. This should not happen > if you use connectToHostEncrypted(). I'm not actually going to call connectToHostEncrypted() as I'm implementing an HTTP server as a subclass of QTcpServer. My understanding was that, once I'd called startServerEncryption() in incoming connection, that nothing would happen until readyRead() was emitted, and that would happen after encryption had succeeded or failed. However, from what you've said, I guess that if an unencrypted client connects, and immediately sends data, then in this case, readyRead() can fire prior to the emission of encrypted(). In which case, if I want a server that handles only encrypted connections, I should a) use the encrypted() signal to indicate via some state in the class that the socket is encrypted b) close the connection immediately in the readyRead() slot unless the socket state is, in fact, encrypted. Does that make sense ? > This is what you've been failing to understand: the ready() slot you're > referring to is *your* slot. It's when you do something. What it is that you > do is entirely up to you. No, I understand that - it's just that I'm not entirely clear what I should be doing with it. -- [ signature omitted ]
On Monday 19 May 2008 11:20:13 Stephen Collyer wrote:
> Thiago Macieira wrote:
> >> 1. Can readyRead() by emitted before encrypted() ?
> >> If so what action should be taken in readyRead() if this occurs ?
> >
> > Yes, it can happen. If you get to readyRead() before encrypted(), it
> > means the data is unencrypted or it's the encryption handshake. This
> > should not happen if you use connectToHostEncrypted().
>
> I'm not actually going to call connectToHostEncrypted() as I'm
> implementing an HTTP server as a subclass of QTcpServer.
>
> My understanding was that, once I'd called startServerEncryption()
> in incoming connection, that nothing would happen until readyRead()
> was emitted, and that would happen after encryption had succeeded
> or failed. However, from what you've said, I guess that if an
> unencrypted client connects, and immediately sends data, then
> in this case, readyRead() can fire prior to the emission of encrypted().
No. If you call start{Client,Server}Encryption, then the encryption will have
either completely succeeded or failed if by the next readyRead().
Which means that, if the client sends unencrypted data instead of the SSL/TLS
handshake, the encryption will fail. And the junk that the client sent will
not be available for you, since the OpenSSL backend will have consumed it
trying to establish the SSL/TLS session.
> In which case, if I want a server that handles only encrypted
> connections, I should
>
> a) use the encrypted() signal to indicate via some state in the
> class that the socket is encrypted
> b) close the connection immediately in the readyRead() slot unless
> the socket state is, in fact, encrypted.
>
> Does that make sense ?
Yes. The encryption handshake can fail, but the socket may still be open after
that and there may be data (junk or not) coming afterwards.
You can also simply query the QSslSocket and ask it if it is encrypted. You
don't have to use the encrypted() signal to set a flag.
--
[ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.
Thiago Macieira wrote:
>> My understanding was that, once I'd called startServerEncryption()
>> in incoming connection, that nothing would happen until readyRead()
>> was emitted, and that would happen after encryption had succeeded
>> or failed. However, from what you've said, I guess that if an
>> unencrypted client connects, and immediately sends data, then
>> in this case, readyRead() can fire prior to the emission of encrypted().
>
> No. If you call start{Client,Server}Encryption, then the encryption will have
> either completely succeeded or failed if by the next readyRead().
OK, that's good.
> Which means that, if the client sends unencrypted data instead of the SSL/TLS
> handshake, the encryption will fail. And the junk that the client sent will
> not be available for you, since the OpenSSL backend will have consumed it
> trying to establish the SSL/TLS session.
But presumably Qt may not consume the whole of the
unencrypted data already in the socket buffer, and
presumably this unencrypted data will be available for
reading if readyReady() is ever emitted again ?
>> In which case, if I want a server that handles only encrypted
>> connections, I should
>>
>> a) use the encrypted() signal to indicate via some state in the
>> class that the socket is encrypted
>> b) close the connection immediately in the readyRead() slot unless
>> the socket state is, in fact, encrypted.
>>
>> Does that make sense ?
>
> Yes. The encryption handshake can fail, but the socket may still be open after
> that and there may be data (junk or not) coming afterwards.
OK (or as I suggested, already-received-but-unconsumed data)
> You can also simply query the QSslSocket and ask it if it is encrypted. You
> don't have to use the encrypted() signal to set a flag.
Presumably via isEncrypted() rather than mode() which doesn't
seem to be useful in this context ?
So if I've understood correctly, encrypted() is going to
be useful mainly in those cases where the server must receive
data in unencrypted mode and later switch to encrypted, at
which point some internal state can be set up to reflect the
change ?
--
[ signature omitted ]
On Monday 19 May 2008 11:51:52 Stephen Collyer wrote: > > Which means that, if the client sends unencrypted data instead of the > > SSL/TLS handshake, the encryption will fail. And the junk that the client > > sent will not be available for you, since the OpenSSL backend will have > > consumed it trying to establish the SSL/TLS session. > > But presumably Qt may not consume the whole of the > unencrypted data already in the socket buffer, and > presumably this unencrypted data will be available for > reading if readyReady() is ever emitted again ? Correct. But you can't tell how much of that data will be available. Some of it will have been consumed, so a failed SSL handshake should usually be followed by disconnection. Unless your protocol specifies some way of recovering from desynchronisation -- which HTTP doesn't. > Presumably via isEncrypted() rather than mode() which doesn't > seem to be useful in this context ? > > So if I've understood correctly, encrypted() is going to > be useful mainly in those cases where the server must receive > data in unencrypted mode and later switch to encrypted, at > which point some internal state can be set up to reflect the > change ? Yes, for instance turning the URL line edit yellow and closing the padlock in a browser. -- [ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.
Thiago Macieira wrote: > On Monday 19 May 2008 11:51:52 Stephen Collyer wrote: >>> Which means that, if the client sends unencrypted data instead of the >>> SSL/TLS handshake, the encryption will fail. And the junk that the client >>> sent will not be available for you, since the OpenSSL backend will have >>> consumed it trying to establish the SSL/TLS session. >> But presumably Qt may not consume the whole of the >> unencrypted data already in the socket buffer, and >> presumably this unencrypted data will be available for >> reading if readyReady() is ever emitted again ? > > Correct. But you can't tell how much of that data will be available. Some of > it will have been consumed, so a failed SSL handshake should usually be > followed by disconnection. Right. I wasn't suggesting that it would be useful data, merely that it would still be present. >> Presumably via isEncrypted() rather than mode() which doesn't >> seem to be useful in this context ? >> >> So if I've understood correctly, encrypted() is going to >> be useful mainly in those cases where the server must receive >> data in unencrypted mode and later switch to encrypted, at >> which point some internal state can be set up to reflect the >> change ? > > Yes, for instance turning the URL line edit yellow and closing the padlock in > a browser. OK, thanks for the explanations; this all makes a lot more sense to me now. BTW, QTcpServer makes the construction of TCP servers very straightforward and I like it a lot. However, does Trolltech have any plans for QHttpServer/QFtpServer etc classes in the future ? It would be very nice to have, say, a fully compliant HTTP 1.1 server available - there are a lot of edge cases to account for, even if basic functionality is reasonably straightforward. -- [ signature omitted ]
On Monday 19 May 2008 13:33:09 Stephen Collyer wrote: > BTW, QTcpServer makes the construction of TCP servers very > straightforward and I like it a lot. However, does Trolltech > have any plans for QHttpServer/QFtpServer etc classes in the > future ? It would be very nice to have, say, a fully compliant > HTTP 1.1 server available - there are a lot of edge cases to > account for, even if basic functionality is reasonably straightforward. No. HTTP servers are extremely difficult to implement, especially given all the variables associated with that. The HTTP/1.1 *client* implementation consumed about 6 man-months to implement and we're still seeing issues with some servers. And that's because servers generally cope with broken clients, not the other way around. Implementing the server would probably be double that effort, at least, plus a good deal of testing with different User Agents. Not to mention the security risk associated with it. The same goes for FTP servers, with the added issue that it's much less requested and used. -- [ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.
Thiago Macieira wrote: > On Monday 19 May 2008 13:33:09 Stephen Collyer wrote: >> BTW, QTcpServer makes the construction of TCP servers very >> straightforward and I like it a lot. However, does Trolltech >> have any plans for QHttpServer/QFtpServer etc classes in the >> future ? It would be very nice to have, say, a fully compliant >> HTTP 1.1 server available - there are a lot of edge cases to >> account for, even if basic functionality is reasonably straightforward. > > No. Is that "No, never", or "No, but yes if we had enough people to do it" ? > Not to mention the security risk associated with it. I'm not sure I see any particular security risk - if someone needs an HTTP server, they have to handle any security issues just as much if they wrote the code as if Trolltech wrote it. -- [ signature omitted ]
On Monday 19 May 2008 15:38:18 Stephen Collyer wrote: > Thiago Macieira wrote: > > On Monday 19 May 2008 13:33:09 Stephen Collyer wrote: > >> BTW, QTcpServer makes the construction of TCP servers very > >> straightforward and I like it a lot. However, does Trolltech > >> have any plans for QHttpServer/QFtpServer etc classes in the > >> future ? It would be very nice to have, say, a fully compliant > >> HTTP 1.1 server available - there are a lot of edge cases to > >> account for, even if basic functionality is reasonably straightforward. > > > > No. > > Is that "No, never", or "No, but yes if we had enough people to do it" ? Something in-between. It would require a great deal of people requesting it and a clear purpose for it (such as a web services module for Qt, like serving SOAP). "Never" is too far away. :-) > > Not to mention the security risk associated with it. > > I'm not sure I see any particular security risk - if someone needs > an HTTP server, they have to handle any security issues just as much > if they wrote the code as if Trolltech wrote it. Yeah, but who gets the blame if there's an issue? :-P -- [ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.
Am Montag, 19. Mai 2008 schrieb Thiago Macieira: > On Monday 19 May 2008 15:38:18 Stephen Collyer wrote: > > Thiago Macieira wrote: > > > Not to mention the security risk associated with it. > > I'm not sure I see any particular security risk - if someone needs > > an HTTP server, they have to handle any security issues just as much > > if they wrote the code as if Trolltech wrote it. > Yeah, but who gets the blame if there's an issue? :-P Especially as some people pay for using (and relying on) Qt... @Stephen: Maybe its easier for you to rip apache/lighttp for the parts you need instead of trying to reinvent the wheel? Arnold -- [ signature omitted ]
Attachment:
signature.asc
Description: This is a digitally signed message part.