Programiranje

Nasvet Java 96: V odjemalski kodi Java uporabite HTTPS

Če ste kdaj poskusili uvesti varno komunikacijo med odjemalcem Java in strežnikom HTTPS (HyperText Transfer Protocol Secure), ste verjetno odkrili, da standard java.net.URL razred ne podpira protokola HTTPS. Izvedba te enačbe na strežniški strani je dokaj enostavna. Skoraj vsak spletni strežnik, ki je danes na voljo, ponuja mehanizem za zahtevanje podatkov s pomočjo HTTPS. Ko nastavite spletni strežnik, lahko kateri koli brskalnik od njega zahteva varne podatke, tako da kot protokol za URL navede protokol HTTPS. Če še nimate nastavljenega strežnika HTTPS, lahko kodo odjemalca preizkusite s skoraj katero koli spletno stranjo HTTPS v internetu. Oddelek Viri vsebuje ožji seznam kandidatov, ki jih lahko uporabite v ta namen.

Z vidika stranke pa preprostost S na koncu znanega HTTP zavaja. Brskalnik dejansko opravlja veliko zakulisnih del, da bi zagotovil, da nihče ni spreminjal ali nadzoroval zahtevanih informacij. Izkazalo se je, da je algoritem za šifriranje za HTTPS patentiral RSA Security (še vsaj nekaj mesecev). Uporabo tega algoritma so dovolili proizvajalci brskalnikov, vendar Sun Microsystems ni dovolil vključitve v standardno Javo URL izvedba razreda. Kot rezultat, če poskušate sestaviti a URL objekt z nizom, ki kot protokol določa HTTPS, a Napačno oblikovanaURLException bo vržen.

Na srečo specifikacija Java za prilagoditev tej omejitvi omogoča možnost izbire nadomestnega obdelovalca toka za URL razred. Vendar je tehnika, potrebna za izvajanje, drugačna, odvisno od navideznega stroja (VM), ki ga uporabljate. Za Microsoftov VM, združljiv z JDK 1.1, JView, je Microsoft licenciral algoritem in zagotovil upravljalnik tokov HTTPS kot del svojega wininet paket. Sun pa je pred kratkim izdal razširitev Java Secure Sockets Extension (JSSE) za VM, združljive z JDK 1.2, v kateri je Sun prav tako licenciral in zagotovil HTTPS-obdelovalec tokov. Ta članek bo prikazal, kako izvajati uporabo upravljalnika tokov, ki podpira HTTPS, z uporabo JSSE in Microsoftovega wininet paket.

Navidezni stroji, združljivi z JDK 1.2

Tehnika uporabe VM-jev, združljivih z JDK 1.2, temelji predvsem na razširitvi Java Secure Sockets Extension (JSSE) 1.0.1. Preden bo ta tehnika delovala, morate namestiti JSSE in ga dodati na pot razreda zadevnega odjemalskega VM.

Ko namestite JSSE, morate nastaviti sistemsko lastnost in dodati novega ponudnika varnosti Varnost predmet razreda. Oboje lahko storite na različne načine, vendar je za namene tega članka prikazana programska metoda:

 System.setProperty ("java.protocol.handler.pkgs", "com.sun.net.ssl.internal.www.protocol"); Security.addProvider (novo com.sun.net.ssl.internal.ssl.Provider ());

Po opravljenih prejšnjih dveh klicih se metoda Napačno oblikovanaURLException ne bo več vržen s klicanjem naslednje kode:

 URL url = nov URL ("// [vaš strežnik]");

Če se povezujete s standardnimi vrati SSL, 443, lahko dodate številko vrat v niz URL-ja. Če pa vaš spletni strežnik za promet SSL uporablja nestandardna vrata, boste morali svojemu URL-ju dodati številko vrat, kot je ta:

 URL url = nov URL ("// [vaš strežnik]: 7002");

Eno opozorilo pri tej tehniki se nanaša na URL, ki se nanaša na strežnik, ki ima nepodpisano ali neveljavno potrdilo SSL. V tem primeru bo poskus pridobivanja vhodnega ali izhodnega toka iz predmeta povezave URL vrgel SSLException s sporočilom "veriga cert-ov nezaupnega strežnika." Če ima strežnik veljavno podpisano potrdilo, nobena izjema ne bo vržena.

 URL url = nov URL ("// [vaš strežnik]"); URLConnection con = URL.openConnection (); // Tu vržemo SSLException, če je potrdilo strežnika neveljavno con.getInputStream ();

Očitna rešitev te težave je pridobiti podpisana potrdila za svoj strežnik. Rešitev pa lahko nudi tudi eden od naslednjih URL-jev: "Java Secure Socket Extension 1.0.2 Changes" (Sun Microsystems) ali Sun's Java Developer Connection forum.

Microsoft JView

Delno zaradi nenehnega spora med Microsoftom in Sunom glede licenciranja Jave za uporabo na platformah Windows je Microsoft JView VM trenutno skladen le z JDK 1.1. Zato zgoraj opisana tehnika ne bo delovala za odjemalce, ki se izvajajo v JView, saj JSSE zahteva vsaj 1.2.2 združljiv VM. Vendar je Microsoft dovolj priročno, da kot del strežnika Windows nudi obdelavo tokov, ki podpira HTTPS com.ms.net.wininet paket.

Obdelovalca toka lahko nastavite v okolju JView, tako da na datoteko pokličete eno samo statično metodo URL razred:

 URL.setURLStreamHandlerFactory (novo com.ms.net.wininet.WininetStreamHandlerFactory ());

Po klicu prejšnje metode se

Napačno oblikovanaURLException

ne bo več vržen s klicem naslednje kode:

 URL url = nov URL ("// [vaš strežnik]");

S to tehniko sta povezani dve opozorili. Prvič, v skladu z dokumentacijo JDK je setURLStreamHandlerFactory metoda lahko v določeni VM pokliče največ enkrat. Kasnejši poskusi klica te metode bodo vrgli Napaka. Drugič, tako kot pri rešitvi 1.2 VM, morate biti previdni pri uporabi URL-ja, ki se nanaša na strežnik z nepodpisanim ali neveljavnim potrdilom SSL. Tako kot v prejšnjem primeru se tudi pri poskusu pridobivanja vhodnega ali izhodnega toka iz predmeta povezave URL-ja pojavijo težave. Namesto da bi vrgli SSLException, obdelava tokov Microsoft vrže standard IOException.

 URL url = nov URL ("// [vaš strežnik]"); URLConnection con = url.openConnection (); // IOException vržen sem, če je potrdilo strežnika neveljavno con.getInputStream ();

Ponovno je očitna rešitev te težave poskus HTTPS komunikacije samo s strežniki, ki imajo podpisano veljavno potrdilo. Vendar pa JView ponuja še eno možnost. Neposredno pred pridobivanjem vhodnega ali izhodnega toka iz predmeta povezave URL-ja lahko pokličete setAllowUserInteraction (true) na objektu povezave. To bo povzročilo, da bo JView prikazal sporočilo, ki bo uporabnika opozorilo, da so potrdila strežnika neveljavna, vendar mu bo dal možnost, da vseeno nadaljuje. Upoštevajte pa, da so takšna sporočila morda smiselna za namizno aplikacijo, toda pogovorna okna na strežniku, ki niso namenjena odpravljanju napak, je verjetno nesprejemljiva.

Opomba: Pokličete lahko tudi setAllowUserInteraction () metoda v VM, združljivih z JDK 1.2. Vendar pa pri uporabi Sun-ove 1.2 VM (s katero je bila preizkušena ta koda), pogovorna okna niso prikazana, tudi če je ta lastnost nastavljena na true.

 URL url = nov URL ("// [vaš strežnik]"); URLConnection con = url.openConnection (); // povzroči, da VM pri povezovanju // z nezaupljivimi strežniki prikaže pogovorno okno con.setAllowUserInteraction (true); con.getInputStream ();

The com.ms.net.wininet Zdi se, da je paket privzeto nameščen in nameščen na sistemsko učno pot v sistemih Windows NT 4.0, Windows 2000 in Windows 9x. V skladu z dokumentacijo Microsofta JDK WinInetStreamHandlerFactory je "... isti upravljalnik, ki je privzeto nameščen med izvajanjem programčkov."

Neodvisnost platforme

Čeprav obe tehniki, ki sem ju opisal, pokrivata večino platform, na katerih se lahko izvaja vaš odjemalec Java, bo moral vaš odjemalec Java delovati na VM, skladnih z JDK 1.1 in JDK 1.2. "Napiši enkrat, teci kjerkoli," se spomniš? Izkazalo se je, da je kombinacija teh dveh tehnik, tako da je ustrezen vodnik naložen, odvisno od VM, dokaj enostavna. Naslednja koda prikazuje en način, kako to storiti:

 Niz strVendor = System.getProperty ("java.vendor"); Niz strVersion = System.getProperty ("java.version"); // Predpostavlja sistemsko različico niza v obliki: //[major].[minor].[release] (npr. 1.2.2) Double dVersion = new Double (strVersion.substring (0, 3)); // Če se izvajamo v okolju MS, uporabite upravljalnik tokov MS. če (-1 <strVendor.indexOf ("Microsoft")) {poskusite {Class clsFactory = Class.forName ("com.ms.net.wininet.WininetStreamHandlerFactory"); if (null! = clsFactory) URL.setURLStreamHandlerFactory ((URLStreamHandlerFactory) clsFactory.newInstance ()); } catch (ClassNotFoundException cfe) {throw new Exception ("Ni mogoče naložiti obdelovalca toka Microsoft SSL" + ". Preveri classpath." + cfe.toString ()); } // Če je bila tovarna upravljavca tokov // že uspešno nastavljena // prepričajte se, da je zastava zastavljena in pojejte napako (Error err) {m_bStreamHandlerSet = true;}} // Če smo v običajnem okolju Java // poskusimo uporabiti obdelovalec JSSE. // OPOMBA: JSSE zahteva 1.2 ali boljšo različico, če je (1.2 <= dVersion.doubleValue ()) {System.setProperty ("java.protocol.handler.pkgs", "com.sun.net.ssl.internal.www.protocol "); poskusite {// če imamo na voljo ponudnika JSSE, // in še ni // nastavljen, ga dodajte kot novo ponudbo v razred Varnost. Razred clsFactory = Class.forName ("com.sun.net.ssl.internal.ssl.Provider"); if ((null! = clsFactory) && (null == Security.getProvider ("SunJSSE"))) Security.addProvider ((Provider) clsFactory.newInstance ()); } catch (ClassNotFoundException cfe) {throw new Exception ("Ni mogoče naložiti upravljavca toka JSSE SSL." + "Preveri pot do razreda." + cfe.toString ()); }}

Kaj pa apleti?

Izvajanje komunikacije, ki temelji na HTTPS, znotraj apleta se zdi naravno podaljšanje zgoraj opisanih scenarijev. V resnici je v večini primerov še lažje. V 4.0 in novejših različicah Netscape Navigatorja in Internet Explorerja je HTTPS privzeto omogočen za njune VM-je. Če želite torej v kodi programčka ustvariti povezavo HTTPS, pri ustvarjanju primerka datoteke preprosto določite HTTPS kot svoj protokol. URL razred:

 URL url = nov URL ("// [vaš strežnik]");

Če se v odjemalskem brskalniku izvaja Sun-ov vtičnik Java 2, obstajajo dodatne omejitve glede uporabe HTTPS. Celotno razpravo o uporabi HTTPS z vtičnikom Java 2 najdete na spletnem mestu Sun (glejte Viri).

Zaključek

Uporaba protokola HTTPS med aplikacijami je lahko hiter in učinkovit način za doseganje primerne ravni varnosti v komunikaciji. Žal so razlogi, da ni podprt kot del standardne specifikacije Java, bolj zakoniti kot tehnični. Vendar pa s prihodom JSSE in uporabo Microsofta com.ms.net.winint paket, je varna komunikacija možna z večine platform z le nekaj vrsticami kode.

Matt Towers, eBozo, ki ga je sam opisal, je pred kratkim zapustil svoj razvojni položaj pri Visiju. Od takrat se je pridružil internetnemu zagonskemu podjetju PredictPoint.com v Seattlu v zvezni državi Washington, kjer dela kot redni razvijalec Java.

Preberite več o tej temi

  • Zip datoteka izvorne kode za ta članek vsebuje zgoraj prikazano kodo, neodvisno od platforme, implementirano v razredu z imenom HttpsMessage. HttpsMessage je namenjen podrazredu HttpMessage razred napisal Jason Hunter, avtor knjige Programiranje Java Servlet (O'Reilly & Associates). Iskati HttpsMessage v prihajajoči drugi izdaji svoje knjige. Če želite uporabiti ta razred, kot je bilo predvideno, boste morali prenesti in namestiti com.oreilly.servlets paket. The com.oreilly.servlets paket in ustrezno izvorno kodo najdete na Hunterjevi spletni strani

    //www.servlets.com

  • Prenesete lahko tudi izvorno datoteko zip

    //images.techhive.com/downloads/idge/imported/article/jvw/2000/06/httpsmessage.zip

  • Tu je nekaj dobrih spletnih strani za testiranje komunikacije HTTPS:
  • //www.verisign.com/
  • //happiness.dhs.org/
  • //www.microsoft.com
  • //www.sun.com
  • //www.ftc.gov
  • Več informacij o JSSE kot tudi o prenosih bitov in navodilih za namestitev najdete na spletnem mestu Sun

    //java.sun.com/products/jsse/.

  • Opis uporabe nekaterih storitev JSSE, vključno z zgoraj opisano tehniko, najdete v "Varno mreženje v Javi" Jonathana Knudsena na spletnem mestu O'Reilly

    //java.oreilly.com/bite-size/java_1099.html

  • Več informacij o WininetStreamHandlerFactory razreda najdete v Microsoftovi dokumentaciji JSDK

    //www.microsoft.com/java/sdk/. Poleg tega Microsoftova baza znanja objavlja tudi "PRBAopustitev razreda URL za dostop do HTTPS v aplikacijah"

    //support.microsoft.com/support/kb/articles/Q191/1/20.ASP

  • Za več informacij o uporabi HTTPS z vtičnikom Java 2 glejte "Kako deluje HTTPS v vtičniku Java" na spletnem mestu Sun

    //java.sun.com/products/plugin/1.2/docs/https.html

To zgodbo "Java Nasvet 96: Uporabite HTTPS v odjemalski kodi Java" je prvotno objavil JavaWorld.

Morda vam bo všeč tudi

$config[zx-auto] not found$config[zx-overlay] not found