Re: [JXTA discuss] problem with secure BiDiPipes
"amoretti" <[email protected]> Sat, 30 Apr 2005 12:48:09 +0200
| Newsgroups | gmane.comp.java.jxta.general |
|---|---|
| Message-ID | <[email protected]> |
OK we solved the problem.... The self-signed cert. of the admin peer resulted to be 8 minutes in the future to the edge peer (host machines were not synchronized). Your suggestions were helpful, thank you again! ;) Michele --- Mohamed Abdelaziz <[email protected]> ha scritto: > > It may be age related. To reveal more info on the Handshake failure turn > on javax.net debugging, you can do so by defining the following > -Djavax.net.debug=all,verbose. > > Mohamed > > > amoretti wrote: > > >--- Mohamed Abdelaziz <[email protected]> ha scritto: > > > > > >>Michele, > >> > >>Ensure the Following : > >> > >> - Both peers must have established credentials at the NetPeerGroup > >>level, as TLS is shared for all groups and cred. must be established > >>within npg (it looks you have done so) > >> - Both peers must have exchanged and persisted each's public cert by > >>some means (See shell pse.* commands for reference) > >> > >> > > > >Yes, this is OK (I did not write it because it is an issue I solved 2 > months > >ago). > > > >I better explain the scenario: > > > >- edge connects to rdv1 and searches for a "secure group adv." > >- the adv. is found, it contains some info about the secure group, e.g. > that > >the group requires a CA-signed cert; infos about the CA are provided > >- edge finds the CA, which is rdv2; the edge disconnects from rdv1 and > >connects to rdv2; mutual exchange of certs; > >(**) then the edge opens a secure (TLS-based) bidipipe with rdv2 (the CA), > >asks for the CA-signed cert., receives the CA-signed cert. > >- now the edge searches for an "admin" peer of the secure group (admin's > name > >are all the same, written in the group adv.) > >- the edge finds the admin, which is rdv3; the edge disconnects from rdv2 > and > >connects to rdv3; mutual exchange of certs; > >(****) then TRIES to open a secure (TLS-based) bidipipe with rdv3 (the > admin) > >but the handshake FAILS (see logs in previous mail) > > > >why this? import cert. is correctly executed, but the handshake fails.. > > > >NOTES: > >The code in (**) and (****) is EXACTLY the same, but only in one case it > >works; > >all previously reported operations are performed in the NPG (a private one, > >we do not use public rdvs); > >all rdvs addresses:ports are known in advance (although this should not be > >necessary, I think) by each peer; > >I am using jxta 2.3.3, of course. > > > >Thanks > > > >Michele > > > > > > > > > >>Ciao, > >>Mohamed > >> > >>amoretti wrote: > >> > >> > >> > >>>Hello, > >>> > >>>I created a private JXTA network with some peers. > >>>In this scenario, consider an edge peer and a rdv peer. > >>>The edge peer authenticates itself to PSEMembershipService, > >>>then creates a secure Pipe advertisement (JXTAUnicastSecure) that is > >>>published in the > >>>NetPeerGroup. Finally, edge peer creates a JxtaServerPipe (with this pipe > >>>adv) and > >>>waits for an incoming connection: > >>> > >>>.. > >>>JxtaServerPipe myServerPipe = null; > >>>myServerPipe = new JxtaServerPipe( netPeerGroup, securePipeAdv ); > >>>// We want to block until a connection is established > >>>myServerPipe.setPipeTimeout(0); > >>> > >>>bidPipe = myServerPipe.accept(); > >>>if( bidPipe != null ) { > >>> System.out.println("JxtaBidiPipe accepted!"); > >>> ... > >>>} > >>>.. > >>> > >>>The rdv peer (which is started later), first authenticates itself to > >>>PSEMembershipService, > >>>then searches (by Name) for the secure pipe adv. previously published by > >>> > >>> > >>edge > >> > >> > >>>peer: when > >>>it founds it, the rdv starts a JxtaBiDiPipe for communicating with edge > >>> > >>> > >>peer: > >> > >> > >>>.. > >>>JxtaBiDiPipe myBidPipe = null; > >>>try { > >>> myBidPipe = new JxtaBiDiPipe(); > >>> myBidPipe.setReliable(true); > >>> > >>> myBidPipe.connect( npg, > >>> peerID, > >>> securePipeAdv, > >>> 120 * 1000, // timeout = 2 min > >>> this); // register as message listener > >>>} catch( Exception e ) { > >>> ... > >>>} > >>>.. > >>> > >>>(npg identifies the NetPeerGroup, peerID is the peerID of the edge peer > >>> > >>> > >and > > > > > >>>securePipeAdv the > >>>secure pipe adv found). > >>> > >>>Unfortunately, the program shows this error message during BiDiPipe > >>>synchronization phase: > >>> > >>>[RDV size] > >>>.. > >>>Start-up JXTA BiDiPipe > >>>[1] ---------------------------------------- > >>>BiDiPipe ad peerID: > >>> > >>> > >>urn:jxta:uuid-59616261646162614A78746150325033B40C0D73F7A74048A90AD5C07966> 9> > >> > >> > >16603 > > > > > >>>Printing Pipe Adv content: > >>>ID: > >>> > >>> > >>urn:jxta:uuid-52FD4619D90D4476ACDBA0EA0AD54482DD22AB289C514936BFC7E26D45A3> 1> > >> > >> > >19E04 > > > > > >>>Name: Testing Secure Pipe connection > >>>Type: JxtaUnicastSecure > >>>Desc: > >>> > >>> > >>urn:jxta:uuid-59616261646162614A78746150325033B40C0D73F7A74048A90AD5C07966> 9> > >> > >> > >16603 > > > > > >>>[1] Attempting to establish a connection... (1)<DEBUG 2005-04-28 > >>>19:15:35,612 PipeServiceImpl::createInputPipe:370> Create > >>> > >>> > >JxtaUnicastSecure > > > > > >>>InputPipe for > >>> > >>> > >>urn:jxta:uuid-52FD4619D90D4476ACDBA0EA0AD544827132EE040D9249178C27E874617C> E> > >> > >> > >3CE04 > > > > > >>><INFO 2005-04-28 19:15:35,613 InputPipeImpl::<init>:115> Creating > >>>InputPipe for > >>> > >>> > >>urn:jxta:uuid-52FD4619D90D4476ACDBA0EA0AD544827132EE040D9249178C27E874617C> E> > >> > >> > >3CE04 of type JxtaUnicastSecure with listener > > > > > >>><DEBUG 2005-04-28 19:15:35,657 PipeServiceImpl::createOutputPipe:518> > >>>Create JxtaUnicastSecure OutputPipe for > >>> > >>> > >>urn:jxta:uuid-52FD4619D90D4476ACDBA0EA0AD54482DD22AB289C514936BFC7E26D45A3> 1> > >> > >> > >19E04 > > > > > >>><DEBUG 2005-04-28 19:15:35,667 JxtaBiDiPipe::connect:339> Waiting for > >>>30000 msec > >>><INFO 2005-04-28 19:15:35,729 NonBlockingOutputPipe::<init>:264> > >>>Constructing for > >>> > >>> > >>urn:jxta:uuid-52FD4619D90D4476ACDBA0EA0AD54482DD22AB289C514936BFC7E26D45A3> 1> > >> > >> > >19E04 > > > > > >>><INFO 2005-04-28 19:15:35,738 > >>>NonBlockingOutputPipe::startServiceThread:713> Thread start : Worker > >>> > >>> > >Thread > > > > > >>>for NonBlockingOutputPipe : > >>> > >>> > >>urn:jxta:uuid-52FD4619D90D4476ACDBA0EA0AD54482DD22AB289C514936BFC7E26D45A3> 1> > >> > >> > >19E04 > > > > > >>> worker state : ACQUIREMESSENGER queue closed : false number in > >>>queue : 0 number queued : 0 number dequeued : 0 > >>><DEBUG 2005-04-28 19:15:35,738 JxtaBiDiPipe::connect:355> Sending a > >>>backchannel message > >>><INFO 2005-04-28 19:15:35,757 TlsConn::<init>:267> Initiating new > >>>connection for : > >>>uuid-59616261646162614A78746150325033B40C0D73F7A74048A90AD5C07966916603 > >>><INFO 2005-04-28 19:15:35,781 JTlsOutputStream::<init>:805> > STARTED > >>>TLS Retransmit thread, RTO = 1000 > >>><INFO 2005-04-28 19:15:35,792 TlsManager::getTlsConn:216> Start of > >>> > >>> > >>client > >> > >> > >>>handshake for > >>>uuid-59616261646162614A78746150325033B40C0D73F7A74048A90AD5C07966916603 > >>><INFO 2005-04-28 19:15:35,793 TlsConn::finishHandshake:376> Client: > >>>Handshake START > >>><INFO 2005-04-28 19:15:35,950 JTlsInputStream::dequeueMessage:509> > >>>DEQUEUED seqn#1 in 154 msec on input queue > >>><INFO 2005-04-28 19:15:36,014 JTlsInputStream::dequeueMessage:509> > >>>DEQUEUED seqn#2 in 27 msec on input queue > >>><INFO 2005-04-28 19:15:36,015 JTlsOutputStream::run:962> STOPPED TLS > >>>Retransmit thread > >>><WARN 2005-04-28 19:15:36,019 TlsManager::getTlsConn:222> Failed > >>> > >>> > >making > > > > > >>>connection to > >>>uuid-59616261646162614A78746150325033B40C0D73F7A74048A90AD5C07966916603 > >>>