https добираются с уязвимыми данными в строке запроса - гарантируют, что данные не хранятся
Linux glibc реализация не может сделать этого.
Но Вы могли расширить его с помощью nss библиотеки, которая могла. Это было бы легко записать, поскольку Вы могли сорвать соответствующую часть libc, который находится в nss_files каталоге в
http://ftp.gnu.org/gnu/glibc/glibc-2.5.tar.bz2
Например,
Это, однако, было бы довольно странной нестандартной вещью сделать.
Трассировка пакетов показала бы, что строка запроса не отправлена в простом тексте (и с возможностью дешифрования SSL wireshark, Вы могли показать, что это отправлено зашифрованное),
Что касается входа, на стороне клиента ответ является определенным, "возможно". Например, кто-то мог быть позади корпоративного прокси, который занимает место, его собственный сертификат SSL (выпущенный CA доверял на всех компьютерах компании), и регистрирует все запросы и вероятно отправляет этот запрос в HR, таким образом, они могут описать человека для траты времени компании на нем.
Никакая идея, если существуют какие-либо другие журналы, что запрос может появиться в на стороне сервера. В зависимости от Вашего приложения (это JSP?) это может даже иметь свои собственные журналы, абсолютно отдельные от IIS.