Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 25 May 2014 20:55:36 +0000 (UTC)
From:      Warren Block <wblock@FreeBSD.org>
To:        doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org
Subject:   svn commit: r44952 - head/en_US.ISO8859-1/books/handbook/security
Message-ID:  <201405252055.s4PKta4V062299@svn.freebsd.org>

next in thread | raw e-mail | index | archive | help
Author: wblock
Date: Sun May 25 20:55:35 2014
New Revision: 44952
URL: http://svnweb.freebsd.org/changeset/doc/44952

Log:
  Whitespace-only fixes.  Translators, please ignore.

Modified:
  head/en_US.ISO8859-1/books/handbook/security/chapter.xml

Modified: head/en_US.ISO8859-1/books/handbook/security/chapter.xml
==============================================================================
--- head/en_US.ISO8859-1/books/handbook/security/chapter.xml	Sun May 25 16:32:53 2014	(r44951)
+++ head/en_US.ISO8859-1/books/handbook/security/chapter.xml	Sun May 25 20:55:35 2014	(r44952)
@@ -4,7 +4,10 @@
 
      $FreeBSD$
 -->
-<chapter xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:id="security">
+<chapter xmlns="http://docbook.org/ns/docbook"
+  xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0"
+  xml:id="security">
+
   <info>
     <title>Security</title>
 
@@ -1083,35 +1086,46 @@ sendmail : PARANOID : deny</programlisti
       <title><application>Kerberos</application></title>
 
       <authorgroup>
-	<author><personname><firstname>Tillman</firstname><surname>Hodgson</surname></personname><contrib>Contributed
-	  by </contrib></author>
+	<author>
+	  <personname>
+	    <firstname>Tillman</firstname>
+	    <surname>Hodgson</surname>
+	  </personname>
+	  <contrib>Contributed by </contrib>
+	</author>
       </authorgroup>
+
       <authorgroup>
-	<author><personname><firstname>Mark</firstname><surname>Murray</surname></personname><contrib>Based
-	  on a contribution by </contrib></author>
+	<author>
+	  <personname>
+	    <firstname>Mark</firstname>
+	    <surname>Murray</surname>
+	  </personname>
+	  <contrib>Based on a contribution by </contrib>
+	</author>
       </authorgroup>
     </info>
 
     <para><application>Kerberos</application> is a network
       authentication protocol which was originally created by the
-      Massachusetts Institute of Technology
-      (<acronym>MIT</acronym>) as a way to securely provide authentication
-      across a potentially hostile network.
-      The <application>Kerberos</application> protocol uses
-      strong cryptography so that both a client and server can prove
-      their identity without sending any unencrypted secrets over the network.
-      <application>Kerberos</application> can be described as an
-      identity-verifying proxy system and as a trusted third-party
-      authentication system.  After a user authenticates with
-      <application>Kerberos</application>, their communications can be
-      encrypted to assure privacy and data integrity.</para>
+      Massachusetts Institute of Technology (<acronym>MIT</acronym>)
+      as a way to securely provide authentication across a potentially
+      hostile network.  The <application>Kerberos</application>
+      protocol uses strong cryptography so that both a client and
+      server can prove their identity without sending any unencrypted
+      secrets over the network.  <application>Kerberos</application>
+      can be described as an identity-verifying proxy system and as a
+      trusted third-party authentication system.  After a user
+      authenticates with <application>Kerberos</application>, their
+      communications can be encrypted to assure privacy and data
+      integrity.</para>
 
     <para>The only function of <application>Kerberos</application> is
-      to provide the secure authentication of users and servers on the network.
-      It does not provide authorization or auditing functions.  It is
-      recommended that <application>Kerberos</application> be used
-      with other security methods which provide authorization and
-      audit services.</para>
+      to provide the secure authentication of users and servers on the
+      network.  It does not provide authorization or auditing
+      functions.  It is recommended that
+      <application>Kerberos</application> be used with other security
+      methods which provide authorization and audit services.</para>
 
     <para>The current version of the protocol is version 5, described
       in <acronym>RFC</acronym>&nbsp;4120.  Several free
@@ -1123,18 +1137,20 @@ sendmail : PARANOID : deny</programlisti
       <acronym>US</acronym> export regulations.  In &os;,
       <acronym>MIT</acronym> <application>Kerberos</application> is
       available as the <package>security/krb5</package> package or
-      port.  The Heimdal <application>Kerberos</application> implementation was
-      explicitly developed outside of the <acronym>US</acronym> to
-      avoid export regulations.  The Heimdal
+      port.  The Heimdal <application>Kerberos</application>
+      implementation was explicitly developed outside of the
+      <acronym>US</acronym> to avoid export regulations.  The Heimdal
       <application>Kerberos</application> distribution is included in
       the base &os; installation, and another distribution with more
-      configurable options is available as <package>security/heimdal</package>
-      in the Ports Collection.</para>
-
-    <para>In <application>Kerberos</application> users and services are
-      identified as <quote>principals</quote> which are contained within
-      an administrative grouping, called a <quote>realm</quote>.  A
-      typical user principal would be of the form
+      configurable options is available as
+      <package>security/heimdal</package> in the Ports
+      Collection.</para>
+
+    <para>In <application>Kerberos</application> users and services
+      are identified as <quote>principals</quote> which are contained
+      within an administrative grouping, called a
+      <quote>realm</quote>.  A typical user principal would be of the
+      form
       <literal><replaceable>user</replaceable>@<replaceable>REALM</replaceable></literal>
       (realms are traditionally uppercase).</para>
 
@@ -1177,14 +1193,15 @@ sendmail : PARANOID : deny</programlisti
 
       <para>The Key Distribution Center (<acronym>KDC</acronym>) is
 	the centralized authentication service that
-	<application>Kerberos</application> provides, the <quote>trusted
-	  third party</quote> of the system.  It is the
+	<application>Kerberos</application> provides, the
+	<quote>trusted third party</quote> of the system.  It is the
 	computer that issues <application>Kerberos</application>
-	tickets, which are used for clients to authenticate to servers.
-	Because the <acronym>KDC</acronym> is considered trusted by
-	all other computers in the
-	<application>Kerberos</application> realm, it has heightened security
-	concerns.  Direct access to the KDC should be limited.</para>
+	tickets, which are used for clients to authenticate to
+	servers.  Because the <acronym>KDC</acronym> is considered
+	trusted by all other computers in the
+	<application>Kerberos</application> realm, it has heightened
+	security concerns.  Direct access to the KDC should be
+	limited.</para>
 
       <para>While running a <acronym>KDC</acronym> requires few
 	computing resources, a dedicated machine acting only as a
@@ -1219,9 +1236,9 @@ kadmind5_server_enable="YES"</programlis
       <para><application>Kerberos</application> can also use the
 	<acronym>DNS</acronym> to locate KDCs, instead of a
 	<literal>[realms]</literal> section in
-	<filename>/etc/krb5.conf</filename>.  For large organizations that
-	have their own <acronym>DNS</acronym> servers, the above example
-	could be trimmed to:</para>
+	<filename>/etc/krb5.conf</filename>.  For large organizations
+	that have their own <acronym>DNS</acronym> servers, the above
+	example could be trimmed to:</para>
 
       <programlisting>[libdefaults]
       default_realm = <replaceable>EXAMPLE.ORG</replaceable>
@@ -1252,22 +1269,22 @@ _kerberos           IN  TXT     <replace
 	database which contains the keys of all principals (users and
 	hosts) encrypted with a master password.  It is not required
 	to remember this password as it will be stored in
-	<filename>/var/heimdal/m-key</filename>; it would be reasonable to
-	use a 45-character random password for this purpose.  To create the
-	master key, run <command>kstash</command> and enter a
-	password:</para>
+	<filename>/var/heimdal/m-key</filename>; it would be
+	reasonable to use a 45-character random password for this
+	purpose.  To create the master key, run
+	<command>kstash</command> and enter a password:</para>
 
       <screen>&prompt.root; <userinput>kstash</userinput>
 Master key: <userinput><replaceable>xxxxxxxxxxxxxxxxxxxxxxx</replaceable></userinput>
 Verifying password - Master key: <userinput><replaceable>xxxxxxxxxxxxxxxxxxxxxxx</replaceable></userinput></screen>
 
-      <para>Once the master key has been created, the database should be
-	initialized.  The <application>Kerberos</application> administrative
-	tool &man.kadmin.8; can be used on the KDC in a mode that
-	operates directly on the database, without using the &man.kadmind.8;
-	network service, as <command>kadmin -l</command>.  
-	This resolves the chicken-and-egg problem of trying to connect to
-	the database
+      <para>Once the master key has been created, the database should
+	be initialized.  The <application>Kerberos</application>
+	administrative tool &man.kadmin.8; can be used on the KDC in a
+	mode that operates directly on the database, without using the
+	&man.kadmind.8; network service, as
+	<command>kadmin -l</command>.  This resolves the
+	chicken-and-egg problem of trying to connect to the database
 	before it is created.  At the <command>kadmin</command>
 	prompt, use <command>init</command> to create the realm's
 	initial database:</para>
@@ -1299,10 +1316,11 @@ Verifying password - Password: <userinpu
 	principal that was just created:</para>
 
       <screen>&prompt.user; <userinput>kinit <replaceable>tillman</replaceable></userinput>
-tillman@EXAMPLE.ORG's Password:
-</screen>
+tillman@EXAMPLE.ORG's Password:</screen>
+
       <para>Confirm that a ticket was successfully obtained using
-      <command>klist</command>:</para>
+	<command>klist</command>:</para>
+
       <screen>&prompt.user; <userinput>klist</userinput>
 Credentials cache: FILE:/tmp/krb5cc_1001
 	Principal: tillman@EXAMPLE.ORG
@@ -1333,49 +1351,52 @@ Aug 27 15:37:58 2013  Aug 28 01:37:58 20
 	regenerated on the new system.</para>
 
       <para>Next, create <filename>/etc/krb5.keytab</filename> on the
-	server.  This is the main part of <quote>Kerberizing</quote> a service
-	&mdash; it corresponds to generating a secret shared between the
-	service and the <acronym>KDC</acronym>.  The secret is a cryptographic
-	key, stored in a <quote>keytab</quote>.  The keytab contains
-	the server's host key, which allows it and the <acronym>KDC</acronym>
-	to verify each others' identity.  It must be transmitted to the
-	server in a secure fashion, as the security of the server can
-	be broken if the key is made public.  Typically, the
+	server.  This is the main part of <quote>Kerberizing</quote> a
+	service &mdash; it corresponds to generating a secret shared
+	between the service and the <acronym>KDC</acronym>.  The
+	secret is a cryptographic key, stored in a
+	<quote>keytab</quote>.  The keytab contains the server's host
+	key, which allows it and the <acronym>KDC</acronym> to verify
+	each others' identity.  It must be transmitted to the server
+	in a secure fashion, as the security of the server can be
+	broken if the key is made public.  Typically, the
 	<filename>keytab</filename> is generated on an administrator's
 	trusted machine using <command>kadmin</command>, then securely
 	transferred to the server, e.g., with &man.scp.1;; it can also
 	be created directly on the server if that is consistent with
 	the desired security policy.  It is very important that the
 	keytab is transmitted to the server in a secure fashion: if
-	the key is known by some other party, that party can impersonate
-	any user to the server!  Using <command>kadmin</command> on the
-	server directly is convenient, because the entry for the host
-	principal in the <acronym>KDC</acronym> database is also created using
+	the key is known by some other party, that party can
+	impersonate any user to the server!  Using
+	<command>kadmin</command> on the server directly is
+	convenient, because the entry for the host principal in the
+	<acronym>KDC</acronym> database is also created using
 	<command>kadmin</command>.</para>
 
-      <para>Of course, <command>kadmin</command> is a kerberized service;
-	a <application>Kerberos</application> ticket is needed to authenticate
-	to the network service, but to ensure that the user running
-	<command>kadmin</command> is actually present (and their session has
-	not been hijacked), <command>kadmin</command> will prompt for the
-	password to get a fresh ticket.  The principal authenticating
-	to the kadmin service must be permitted to use the
-	<command>kadmin</command> interface, as specified in
-	<filename>kadmind.acl</filename>.  See the section titled
-	<quote>Remote administration</quote> in <command>info
-	  heimdal</command> for details on designing access control
-	lists.  Instead of enabling remote <command>kadmin</command>
-	access, the administrator could securely connect to the
-	<acronym>KDC</acronym> via the local console or &man.ssh.1;,
-	and perform administration locally using
-	<command>kadmin -l</command>.</para>
+      <para>Of course, <command>kadmin</command> is a kerberized
+	service; a <application>Kerberos</application> ticket is
+	needed to authenticate to the network service, but to ensure
+	that the user running <command>kadmin</command> is actually
+	present (and their session has not been hijacked),
+	<command>kadmin</command> will prompt for the password to get
+	a fresh ticket.  The principal authenticating to the kadmin
+	service must be permitted to use the <command>kadmin</command>
+	interface, as specified in <filename>kadmind.acl</filename>.
+	See the section titled <quote>Remote administration</quote> in
+	<command>info heimdal</command> for details on designing
+	access control lists.  Instead of enabling remote
+	<command>kadmin</command> access, the administrator could
+	securely connect to the <acronym>KDC</acronym> via the local
+	console or &man.ssh.1;, and perform administration locally
+	using <command>kadmin -l</command>.</para>
 
       <para>After installing <filename>/etc/krb5.conf</filename>,
-	use <command>add --random-key</command> in <command>kadmin</command>.
-	This adds the server's host principal to the database, but does not
-	extract a copy of the host principal key to a keytab.  To generate
-	the keytab, use <command>ext</command> to extract the server's host
-	principal key to its own keytab:</para>
+	use <command>add --random-key</command> in
+	<command>kadmin</command>.  This adds the server's host
+	principal to the database, but does not extract a copy of the
+	host principal key to a keytab.  To generate the keytab, use
+	<command>ext</command> to extract the server's host principal
+	key to its own keytab:</para>
 
       <screen>&prompt.root; <userinput>kadmin</userinput>
 kadmin&gt;<userinput> add --random-key host/myserver.example.org</userinput>
@@ -1387,11 +1408,12 @@ Attributes []:
 kadmin&gt;<userinput> ext_keytab <replaceable>host/myserver.example.org</replaceable></userinput>
 kadmin&gt;<userinput> exit</userinput></screen>
 
-      <para>Note that <command>ext_keytab</command> stores the extracted key
-	in <filename>/etc/krb5.keytab</filename> by default.  This is
-	good when being run on the server being kerberized, but the
-	<command>--keytab <replaceable>path/to/file</replaceable></command>
-	argument should be used when the keytab is being extracted
+      <para>Note that <command>ext_keytab</command> stores the
+	extracted key in <filename>/etc/krb5.keytab</filename> by
+	default.  This is good when being run on the server being
+	kerberized, but the <command>--keytab
+	  <replaceable>path/to/file</replaceable></command> argument
+	should be used when the keytab is being extracted
 	elsewhere:</para>
 
       <screen>&prompt.root; <userinput>kadmin</userinput>
@@ -1400,23 +1422,25 @@ kadmin&gt;<userinput> exit</userinput></
 
       <para>The keytab can then be securely copied to the server
 	using &man.scp.1; or a removable media.  Be sure to specify a
-	non-default keytab name to avoid inserting unneeded keys into the
-	system's keytab.</para>
+	non-default keytab name to avoid inserting unneeded keys into
+	the system's keytab.</para>
 
-      <para>At this point, the server can read encrypted messages from the
-	<acronym>KDC</acronym> using its shared key, stored in
-	<filename>krb5.keytab</filename>.  It is now
-	ready for the <application>Kerberos</application>-using services to
-	be enabled.  One of the most common such services is &man.sshd.8;,
-	which supports <application>Kerberos</application> via the
+      <para>At this point, the server can read encrypted messages from
+	the <acronym>KDC</acronym> using its shared key, stored in
+	<filename>krb5.keytab</filename>.  It is now ready for the
+	<application>Kerberos</application>-using services to be
+	enabled.  One of the most common such services is
+	&man.sshd.8;, which supports
+	<application>Kerberos</application> via the
 	<acronym>GSS-API</acronym>.  In
-	<filename>/etc/ssh/sshd_config</filename>, add the line:</para>
+	<filename>/etc/ssh/sshd_config</filename>, add the
+	line:</para>
 
       <programlisting>GSSAPIAuthentication yes</programlisting>
 
-      <para>After making this change, &man.sshd.8; must be restared for
-	the new configuration to take effect: <command>service sshd
-	restart</command>.</para>
+      <para>After making this change, &man.sshd.8; must be restared
+	for the new configuration to take effect:
+	<command>service sshd restart</command>.</para>
     </sect2>
 
     <sect2>
@@ -1428,34 +1452,35 @@ kadmin&gt;<userinput> exit</userinput></
 	<secondary>configure clients</secondary>
       </indexterm>
 
-      <para>As it was for the server, the client requires configuration in
-	<filename>/etc/krb5.conf</filename>.  Copy the file in place
-	(securely) or re-enter it as needed.</para>
+      <para>As it was for the server, the client requires
+	configuration in <filename>/etc/krb5.conf</filename>.  Copy
+	the file in place (securely) or re-enter it as needed.</para>
 
       <para>Test the client by using <command>kinit</command>,
 	<command>klist</command>, and <command>kdestroy</command> from
-	the client to obtain, show, and then delete a ticket
-	for an existing principal.  <application>Kerberos</application>
+	the client to obtain, show, and then delete a ticket for an
+	existing principal.  <application>Kerberos</application>
 	applications should also be able to connect to
 	<application>Kerberos</application> enabled servers.  If that
 	does not work but obtaining a ticket does, the problem is
 	likely with the server and not with the client or the
-	<acronym>KDC</acronym>.  In the case of kerberized &man.ssh.1;,
-	<acronym>GSS-API</acronym> is disabled by default, so test using
-	<command>ssh -o GSSAPIAuthentication=yes
-	<replaceable>hostname</replaceable></command>.</para>
+	<acronym>KDC</acronym>.  In the case of kerberized
+	&man.ssh.1;, <acronym>GSS-API</acronym> is disabled by
+	default, so test using <command>ssh -o
+	  GSSAPIAuthentication=yes
+	  <replaceable>hostname</replaceable></command>.</para>
 
       <para>When testing a Kerberized application, try using a packet
 	sniffer such as <command>tcpdump</command> to confirm that no
 	sensitive information is sent in the clear.</para>
 
       <para>Various <application>Kerberos</application> client
-	applications are available.  With the advent of a bridge so that
-	applications using <acronym>SASL</acronym> for authentication can
-	use <acronym>GSS-API</acronym> mechanisms as well, large classes
-	of client applications can use <application>Kerberos</application>
-	for authentication, from Jabber clients to <acronym>IMAP</acronym>
-	clients.</para>
+	applications are available.  With the advent of a bridge so
+	that applications using <acronym>SASL</acronym> for
+	authentication can use <acronym>GSS-API</acronym> mechanisms
+	as well, large classes of client applications can use
+	<application>Kerberos</application> for authentication, from
+	Jabber clients to <acronym>IMAP</acronym> clients.</para>
 
       <indexterm>
 	<primary><filename>.k5login</filename></primary>
@@ -1514,8 +1539,8 @@ jdoe@example.org</screen>
 	<acronym>MIT</acronym> versions if <envar>PATH</envar> lists
 	the system directories first.</para>
 
-      <para>When using MIT Kerberos as a <acronym>KDC</acronym> on &os;,
-	the following edits should also be made to
+      <para>When using MIT Kerberos as a <acronym>KDC</acronym> on
+	&os;, the following edits should also be made to
 	<filename>rc.conf</filename>:</para>
 
       <programlisting>kerberos5_server="/usr/local/sbin/krb5kdc"
@@ -1536,9 +1561,9 @@ kadmind5_server_enable="YES"</programlis
       <itemizedlist>
 	<listitem>
 	  <para>When using either Heimdal or <acronym>MIT</acronym>
-	    <application>Kerberos</application> from ports, ensure that the
-	    <envar>PATH</envar> lists the port's versions of the
-	    client applications before the system versions.</para>
+	    <application>Kerberos</application> from ports, ensure
+	    that the <envar>PATH</envar> lists the port's versions of
+	    the client applications before the system versions.</para>
 	</listitem>
 
 	<listitem>
@@ -1580,15 +1605,16 @@ kadmind5_server_enable="YES"</programlis
 
 	<listitem>
 	  <para>With <acronym>MIT</acronym>
-	    <application>Kerberos</application>, to allow a
-	    principal to have a ticket life longer than the default
-	    lifetime of ten hours, use <command>modify_principal</command>
-	    at the &man.kadmin.8; prompt to change the
+	    <application>Kerberos</application>, to allow a principal
+	    to have a ticket life longer than the default lifetime of
+	    ten hours, use <command>modify_principal</command> at the
+	    &man.kadmin.8; prompt to change the
 	    <literal>maxlife</literal> of both the principal in
-	    question and the <systemitem
-	      class="username">krbtgt</systemitem> principal.  The
-	    principal can then use <command>kinit -l</command> to
-	    request a ticket with a longer lifetime.</para>
+	    question and the
+	    <systemitem class="username">krbtgt</systemitem>
+	    principal.  The principal can then use
+	    <command>kinit -l</command> to request a ticket with a
+	    longer lifetime.</para>
 	</listitem>
 
 	<listitem>
@@ -1994,21 +2020,39 @@ Connection closed by foreign host.</scre
 
   <sect1 xml:id="ipsec">
     <info>
-    <title><acronym>VPN</acronym> over
-      <acronym>IPsec</acronym></title>
+      <title><acronym>VPN</acronym> over
+	<acronym>IPsec</acronym></title>
 
       <authorgroup>
-	<author><personname><firstname>Nik</firstname><surname>Clayton</surname></personname><affiliation>
-	    <address><email>nik@FreeBSD.org</email></address>
-	  </affiliation><contrib>Written by </contrib></author>
+	<author>
+	  <personname>
+	    <firstname>Nik</firstname>
+	    <surname>Clayton</surname>
+	  </personname>
+	  <affiliation>
+	    <address>
+	      <email>nik@FreeBSD.org</email>
+	    </address>
+	  </affiliation>
+	  <contrib>Written by </contrib>
+	</author>
       </authorgroup>
-	<authorgroup>
-	  <author><personname><firstname>Hiten
-	    M.</firstname><surname>Pandya</surname></personname><affiliation>
-	      <address><email>hmp@FreeBSD.org</email></address>
-	    </affiliation><contrib>Written by </contrib></author>
-	</authorgroup>
-      </info>
+
+      <authorgroup>
+	<author>
+	  <personname>
+	    <firstname>Hiten M.</firstname>
+	    <surname>Pandya</surname>
+	  </personname>
+	  <affiliation>
+	    <address>
+	      <email>hmp@FreeBSD.org</email>
+	    </address>
+	  </affiliation>
+	  <contrib>Written by </contrib>
+	</author>
+      </authorgroup>
+    </info>
 
     <indexterm>
       <primary><acronym>IPsec</acronym></primary>
@@ -2152,13 +2196,22 @@ device    crypto</screen>
 
     <sect2>
       <info>
-      <title>Configuring a <acronym>VPN</acronym> on &os;</title>
+	<title>Configuring a <acronym>VPN</acronym> on &os;</title>
 
-	  <authorgroup>
-	    <author><personname><firstname>Tom</firstname><surname>Rhodes</surname></personname><affiliation>
-		<address><email>trhodes@FreeBSD.org</email></address>
-	      </affiliation><contrib>Written by </contrib></author>
-	  </authorgroup>
+	<authorgroup>
+	  <author>
+	    <personname>
+	      <firstname>Tom</firstname>
+	      <surname>Rhodes</surname>
+	    </personname>
+	    <affiliation>
+	      <address>
+		<email>trhodes@FreeBSD.org</email>
+	      </address>
+	    </affiliation>
+	    <contrib>Written by </contrib>
+	  </author>
+	</authorgroup>
       </info>
 
       <para>To begin, <package>security/ipsec-tools</package> must be
@@ -2457,7 +2510,7 @@ racoon_enable="yes"</programlisting>
       authentication and encryption methods to prevent this from
       happening.  More information about
       <application>OpenSSH</application> is available from <link
-	  xlink:href="http://www.openssh.com/">http://www.openssh.com/</link>.</para>;
+	xlink:href="http://www.openssh.com/">http://www.openssh.com/</link>.</para>;
 
     <para>This section provides an overview of the built-in client
       utilities to securely access other systems and securely transfer



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201405252055.s4PKta4V062299>